perm filename COMMON.3[COM,LSP] blob
sn#771108 filedate 1984-09-30 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00448 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00053 00002
C00054 00003 ∂17-May-83 2320 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN Break
C00056 00004 ∂18-May-83 0004 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN Conservation of nits
C00070 00005 ∂18-May-83 1030 @MIT-MC:MOON@SCRC-TENEX revised BREAK writeup
C00074 00006 ∂18-May-83 1344 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN writeup on name conflicts
C00089 00007 ∂18-May-83 2123 FAHLMAN@CMU-CS-C Maphash
C00091 00008 ∂18-May-83 2148 FAHLMAN@CMU-CS-C Revenge of the Packages
C00164 00009 ∂18-May-83 2313 Moon@SCRC-TENEX error proposal not so hard to implement
C00165 00010 ∂19-May-83 1457 @MIT-MC:KMP@MIT-MC Comments on wording in "Revenge of the Packages"
C00171 00011 ∂22-May-83 1507 FAHLMAN@CMU-CS-C Last call for nits
C00174 00012 ∂23-May-83 1623 David.Dill@CMU-CS-A EXPORT after USE-PACKAGE
C00176 00013 ∂23-May-83 1639 BENSON@SPA-NIMBUS Return of the Packages Strikes Back
C00180 00014 ∂23-May-83 1713 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN Alphabetic case in package names
C00183 00015 ∂23-May-83 1714 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN EXPORT after USE-PACKAGE
C00186 00016 ∂23-May-83 2047 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN Maphash
C00189 00017 ∂23-May-83 2231 FAHLMAN@CMU-CS-C Maphash
C00192 00018 ∂23-May-83 2304 FAHLMAN@CMU-CS-C Return of the Packages Strikes Back
C00194 00019 ∂23-May-83 2347 Moon@SCRC-TENEX One last diddle to my error proposal
C00196 00020 ∂24-May-83 0910 FAHLMAN@CMU-CS-C One last diddle to my error proposal
C00198 00021 ∂24-May-83 1309 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN One last diddle to my error proposal
C00201 00022 ∂24-May-83 1315 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN One last diddle to my error proposal
C00204 00023 ∂24-May-83 1427 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN maphash and do-hash
C00205 00024 ∂24-May-83 2035 FAHLMAN@CMU-CS-C EXPORT after USE
C00207 00025 ∂25-May-83 0730 David.Dill@CMU-CS-A EXPORT after USE
C00210 00026 ∂25-May-83 1033 David.Dill@CMU-CS-A EXPORT after USE
C00213 00027 ∂25-May-83 1304 @USC-ECL,@MIT-ML:BSG%SCRC-TENEX@MIT-ML REDUCE Change
C00215 00028 ∂25-May-83 1346 @USC-ECL,@MIT-ML:Moon%SCRC-TENEX@MIT-ML REDUCE Change
C00218 00029 ∂25-May-83 1410 @USC-ECL,@MIT-ML:BSG%SCRC-TENEX@MIT-ML REDUCE Change
C00220 00030 ∂25-May-83 1425 @USC-ECL:WHOLEY@CMU-CS-C REDUCE Change
C00223 00031 ∂26-May-83 1016 FAHLMAN@CMU-CS-C Manual update
C00227 00032 ∂26-May-83 2101 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN ENDP
C00229 00033 ∂27-May-83 0055 FAHLMAN@CMU-CS-C ENDP
C00231 00034 ∂27-May-83 1022 RPG Comments on LASER.UPDATE
C00366 00035 ∂25-May-83 0913 FAHLMAN@CMU-CS-C Finishing the Manual: Final Offer
C00375 00036 ∂25-May-83 1158 RPG Common Lisp Offer
C00377 00037 ∂25-May-83 1228 FAHLMAN@CMU-CS-C Offer
C00382 00038 ∂25-May-83 1434 FAHLMAN@CMU-CS-C Offer
C00384 00039 ∂25-May-83 2118 FAHLMAN@CMU-CS-C Follow up
C00394 00040 ∂26-May-83 0753 FAHLMAN@CMU-CS-C Manual update
C00398 00041 ∂26-May-83 1029 JMB@S1-A Common Lisp Calls!
C00400 00042 ∂26-May-83 1151 JMB@S1-A Common Lisp Manual
C00402 00043 ∂27-May-83 0623 FAHLMAN@CMU-CS-C Comments on LASER.UPDATE
C00405 00044 ∂29-May-83 1122 GJC@MIT-MC
C00406 00045 ∂30-May-83 0020 RPG [Moon%SCRC-TENEX: New setf writeup]
C00412 00046 ∂30-May-83 0020 RPG Issues raised by MOON and DLW
C00421 00047 ∂30-May-83 0021 RPG Ok-by-me's
C00422 00048 ∂30-May-83 0021 RPG Issues raised by MOON and DLW
C00440 00049 ∂30-May-83 0021 RPG Changes to Laser edition for APPLYHOOK
C00447 00050 ∂30-May-83 0021 RPG Issues raised by MOON and DLW
C00454 00051 ∂30-May-83 0021 RPG Changes to Laser edition for APPLYHOOK
C00456 00052 ∂30-May-83 0021 RPG Issues raised by MOON and DLW
C00462 00053 ∂30-May-83 0021 RPG Non-ballot
C00470 00054 ∂30-May-83 0021 RPG cmuc:prva:<slisp.scl>laser.reply
C00492 00055 ∂30-May-83 0022 RPG :unspecific issues with pathnames
C00497 00056 ∂30-May-83 0022 RPG Non-ballot
C00506 00057 ∂30-May-83 0022 RPG Left and right parentheses
C00510 00058 ∂30-May-83 0022 RPG More polished DEFSETF
C00512 00059 ∂30-May-83 0022 RPG Package Chapter
C00514 00060 ∂30-May-83 0022 RPG More polished DEFSETF
C00516 00061 ∂30-May-83 0022 RPG [Mailer: Message of 29 May 83 18:40:49 EDT]
C00519 00062 ∂30-May-83 0022 RPG Laser.reply .reply .reply
C00527 00063 ∂30-May-83 0023 RPG Laser.reply .reply .reply
C00532 00064 ∂30-May-83 0023 RPG Laser.reply .reply .reply
C00536 00065 ∂30-May-83 0023 RPG
C00538 00066 ∂30-May-83 0021 FAHLMAN@CMU-CS-C Memorial Day Ballot
C00563 00067 ∂30-May-83 0807 FAHLMAN@CMU-CS-C Memorial Day Ballot
C00567 00068 ∂30-May-83 1205 @USC-ECL:GJC@MIT-ML special characters in package names
C00569 00069 ∂30-May-83 1203 Guy.Steele@CMU-CS-A My replies to Memorial Day Ballot
C00575 00070 ∂30-May-83 1228 WHOLEY@CMU-CS-C Memorial Day Ballot
C00578 00071 ∂30-May-83 1245 Guy.Steele@CMU-CS-A Re: *prindepth* and *prinlength* versus *prinarray*
C00580 00072 ∂30-May-83 1310 HEDRICK@RUTGERS.ARPA SUB-READ and friends
C00582 00073 ∂30-May-83 1317 @MIT-MC:MOON@SCRC-TENEX Memorial Day Ballot comments
C00586 00074 ∂30-May-83 1342 @MIT-MC:MOON@SCRC-TENEX Memorial Day Ballot
C00591 00075 ∂30-May-83 1413 KMP@MIT-MC Memorial Day Ballot
C00600 00076 ∂30-May-83 1602 @MIT-MC:MOON@SCRC-TENEX Memorial Day Ballot comments
C00604 00077 ∂30-May-83 1707 @MIT-MC:MOON@SCRC-TENEX Issue of macro expansion portability
C00611 00078 ∂30-May-83 1718 ALAN@MIT-MC Steele's |:foo| suggestion.
C00615 00079 ∂30-May-83 2200 FAHLMAN@CMU-CS-C ballot issues
C00620 00080 ∂30-May-83 2232 @MIT-MC:kmp@MIT-MC Package names
C00623 00081 ∂30-May-83 2235 FAHLMAN@CMU-CS-C Ballot clarifications
C00627 00082 ∂30-May-83 2252 FAHLMAN@CMU-CS-C Package names
C00629 00083 ∂30-May-83 2328 Guy.Steele@CMU-CS-A Yucky proposed | syntax
C00633 00084 ∂30-May-83 2335 KMP@MIT-MC Package names
C00636 00085 ∂31-May-83 0009 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN yucky package names
C00638 00086 ∂31-May-83 0014 FAHLMAN@CMU-CS-C Non-yucky package names (I think)
C00642 00087 ∂31-May-83 0240 @SU-SCORE.ARPA:JONL.PA@PARC-MAXC.ARPA Holiday Ballot
C00651 00088 ∂31-May-83 0548 @USC-ECL,@MIT-MC:BSG%SCRC-TENEX@MIT-MC A memorial day issue
C00653 00089 ∂31-May-83 0642 @USC-ECL:FAHLMAN@CMU-CS-C A memorial day issue
C00656 00090 ∂31-May-83 0643 FAHLMAN@CMU-CS-C A memorial day issue
C00659 00091 ∂31-May-83 0754 jrg@cmu-cs-spice Memorial Day Ballot
C00661 00092 ∂31-May-83 0857 @USC-ECL,@MIT-MC:BSG%SCRC-TENEX@MIT-MC A memorial day issue
C00667 00093 ∂31-May-83 1043 RPG Memorial Day Ballot
C00693 00094 ∂31-May-83 1205 DDYER@USC-ISIB memorial ballot
C00696 00095 ∂31-May-83 1248 BENSON@SPA-NIMBUS Memorial Day Ballot
C00701 00096 ∂31-May-83 1340 @MIT-MC:DLW%SCRC-TENEX%MIT-MC@SU-DSN Re: *prindepth* and *prinlength* versus *prinarray*
C00703 00097 ∂31-May-83 1358 BENSON@SPA-NIMBUS Fahlman's latest package printing proposal
C00704 00098 ∂31-May-83 1843 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN Memorial Day Ballot: comments on other people's entries
C00714 00099 ∂31-May-83 2032 EAK@MIT-MC Memorial Day Ballot
C00717 00100 ∂31-May-83 2039 EAK@MIT-MC read top-level discussion
C00718 00101 ∂31-May-83 2043 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN floating-point format
C00733 00102 ∂31-May-83 2121 @MIT-MC:BENSON%SPA-NIMBUS%MIT-MC@SU-DSN Memorial Day Ballot: comments on other people's entries
C00740 00103 ∂31-May-83 2149 GSB@MIT-ML mem. day ballot
C00747 00104 ∂31-May-83 2212 Guy.Steele@CMU-CS-A Moon's remarks on ~F,~E,~G,~$
C00750 00105 ∂31-May-83 2231 FAHLMAN@CMU-CS-C grt optys in data proc
C00752 00106 ∂01-Jun-83 0036 GSB@MIT-ML defstruct, and the :named option
C00759 00107 ∂01-Jun-83 0719 FAHLMAN@CMU-CS-C defstruct, and the :named option
C00761 00108 ∂01-Jun-83 1258 KMP@MIT-MC
C00763 00109 ∂01-Jun-83 1352 KMP@MIT-MC (MULTIPLE-VALUE (NIL ...) ...)
C00765 00110 ∂01-Jun-83 1413 Walter.VanRoggen@CMU-CS-A Memorial Day Ballot
C00773 00111 ∂01-Jun-83 1456 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN defstruct, and the :named option
C00776 00112 ∂01-Jun-83 1558 FAHLMAN@CMU-CS-C (MULTIPLE-VALUE (NIL ...) ...)
C00778 00113 ∂01-Jun-83 1602 GSB@MIT-ML randomness
C00780 00114 ∂01-Jun-83 1657 @MIT-MC:HIC%SCRC-TENEX%MIT-MC@SU-DSN Re: defstruct, and the :named option
C00782 00115 ∂01-Jun-83 1751 @SU-SCORE.ARPA:JonL.pa@PARC-MAXC.ARPA Spread Uniformity and Auto-Doc -- your comments
C00788 00116 ∂01-Jun-83 1818 HEDRICK@RUTGERS.ARPA our votes in the Memorial Day Ballot
C00793 00117 ∂01-Jun-83 1927 KMP@MIT-MC NTH-VALUE, some examples
C00797 00118 ∂01-Jun-83 1943 EAK@MIT-MC NTH-VALUE
C00798 00119 ∂01-Jun-83 2158 FAHLMAN@CMU-CS-C Non-yucky package names (I think)
C00800 00120 ∂01-Jun-83 2218 Guy.Steele@CMU-CS-A Re: grt optys in data proc
C00804 00121 ∂01-Jun-83 2251 Guy.Steele@CMU-CS-A Re: randomness
C00806 00122 ∂02-Jun-83 0008 FAHLMAN@CMU-CS-C The envelope please...
C00821 00123 ∂02-Jun-83 0911 @MIT-MC:BSG%SCRC-TENEX%MIT-MC@SU-DSN The envelope please...
C00823 00124 ∂02-Jun-83 1000 FAHLMAN@CMU-CS-C BSG /= GSB
C00825 00125 ∂02-Jun-83 1351 @USC-ECL,@MIT-MC:BSG%SCRC-TENEX@MIT-MC The dogma killed ASET
C00827 00126 ∂02-Jun-83 1504 @MIT-MC:Moon@SCRC-TENEX NTH-VALUE
C00829 00127 ∂02-Jun-83 1506 @MIT-MC:Moon@SCRC-TENEX Non-yucky package names (I think)
C00834 00128 ∂02-Jun-83 1503 @MIT-MC:Moon@SCRC-TENEX Issue 21: package of #+/#- features
C00836 00129 ∂02-Jun-83 1506 @MIT-MC:Moon@SCRC-TENEX #+ hair
C00838 00130 ∂02-Jun-83 1522 @MIT-MC:Moon@SCRC-TENEX ~m,n@T in FORMAT
C00840 00131 ∂02-Jun-83 1621 EAK@MIT-MC grt optys in data proc
C00841 00132 ∂02-Jun-83 1714 EAK@MIT-MC format force-output
C00842 00133 ∂02-Jun-83 1808 FAHLMAN@CMU-CS-C format force-output
C00844 00134 ∂02-Jun-83 2256 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN The dogma killed ASET
C00849 00135 ∂02-Jun-83 2318 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN typep of array
C00851 00136 ∂02-Jun-83 2327 FAHLMAN@CMU-CS-C Another ballot
C00874 00137 ∂03-Jun-83 0649 @MIT-MC:BSG%SCRC-TENEX%MIT-MC@SU-DSN Another ballot
C00886 00138 ∂03-Jun-83 0835 GINDER@CMU-CS-C Re: Another ballot
C00887 00139 ∂03-Jun-83 0838 @MIT-MC:DLW%SCRC-TENEX%MIT-MC@SU-DSN Another ballot
C00892 00140 ∂03-Jun-83 0907 @MIT-ML:DLW%SCRC-TENEX%MIT-ML@SU-DSN Another ballot
C00895 00141 ∂03-Jun-83 0918 @MIT-MC:DLW%SCRC-TENEX%MIT-MC@SU-DSN The dogma killed ASET
C00897 00142 ∂03-Jun-83 0925 @MIT-MC:Cassels%SCRC-TENEX%MIT-MC@SU-DSN [Moon at SCRC-TENEX: short-float-negative-epsilon]
C00899 00143 ∂03-Jun-83 1009 eak@s1-c 2nd ballot
C00902 00144 ∂03-Jun-83 1014 eak@s1-c compiled-function
C00904 00145 ∂03-Jun-83 1049 @MIT-MC:BSG%SCRC-TENEX%MIT-MC@SU-DSN Another ballot
C00906 00146 ∂03-Jun-83 1126 RPG
C00909 00147 ∂03-Jun-83 1153 ALAN@MIT-MC Another ballot
C00912 00148 ∂03-Jun-83 1223 BENSON@SPA-NIMBUS Function names and function objects
C00917 00149 ∂03-Jun-83 1238 BENSON@SPA-NIMBUS Earlier message on function objects
C00930 00150 ∂03-Jun-83 1339 KMP@MIT-MC Another Ballot
C00938 00151 ∂03-Jun-83 1403 @MIT-MC:Cassels@SCRC-TENEX Functions for taking apart floating-point numbers
C00944 00152 ∂03-Jun-83 1431 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN Ballot A
C00956 00153 ∂03-Jun-83 1452 HEDRICK@RUTGERS.ARPA Re: Another ballot
C00963 00154 ∂03-Jun-83 1727 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN PROCLAIM and implicit EVAL-WHEN
C00967 00155 ∂03-Jun-83 1851 Walter.VanRoggen@CMU-CS-A Another ballot
C00969 00156 ∂03-Jun-83 1913 GSB@MIT-ML ballot A
C00974 00157 ∂03-Jun-83 2050 GJC@MIT-ML Destructuring
C00976 00158 ∂03-Jun-83 2052 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN Functions for taking apart floating-point numbers
C00979 00159 ∂03-Jun-83 2115 Guy.Steele@CMU-CS-A Re: typep of array
C00981 00160 ∂03-Jun-83 2124 Guy.Steele@CMU-CS-A Reply to ballot A
C00982 00161 ∂03-Jun-83 2141 Guy.Steele@CMU-CS-A Addendum to my answers on ballot A
C00985 00162 ∂03-Jun-83 2148 Guy.Steele@CMU-CS-A Array rank
C00987 00163 ∂03-Jun-83 2230 Guy.Steele@CMU-CS-A pervasiveness of declarations
C00991 00164 ∂03-Jun-83 2256 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN Addendum to my answers on ballot A
C00995 00165 ∂03-Jun-83 2302 Guy.Steele@CMU-CS-A Copying a random-state
C00996 00166 ∂03-Jun-83 2302 ALAN@MIT-MC Gaussian rationals
C01001 00167 ∂04-Jun-83 1041 fateman%UCBKIM@Berkeley Re: Gaussian rationals
C01003 00168 ∂04-Jun-83 1452 Guy.Steele@CMU-CS-A Volume of mail (trivia)
C01004 00169 ∂04-Jun-83 1515 @MIT-MC:BSG%SCRC-TENEX%MIT-MC@SU-DSN Re: Volume of mail (trivia)
C01006 00170 ∂05-Jun-83 0130 ALAN@MIT-MC Gaussian rationals
C01012 00171 ∂05-Jun-83 0810 FAHLMAN@CMU-CS-C Gaussian rationals
C01017 00172 ∂05-Jun-83 1054 FAHLMAN@CMU-CS-C Results of ballot A
C01028 00173 ∂05-Jun-83 1112 fateman%UCBKIM@Berkeley gaussian rationals
C01031 00174 ∂05-Jun-83 1111 @MIT-MC:MOON@SCRC-TENEX Proposed elimination of mixed-type complex numbers
C01033 00175 ∂05-Jun-83 1226 EAK@MIT-MC Results of ballot A
C01034 00176 ∂05-Jun-83 1241 FAHLMAN@CMU-CS-C Results of ballot A
C01036 00177 ∂05-Jun-83 1557 ALAN@MIT-MC gaussian rationals, transcendental functions, etc.
C01040 00178 ∂05-Jun-83 1700 FAHLMAN@CMU-CS-C gaussian rationals, transcendental functions, etc.
C01043 00179 ∂05-Jun-83 1755 GJC@MIT-ML Complex Arguments, fear and loathing on the number line.
C01046 00180 ∂05-Jun-83 1945 Walter.VanRoggen@CMU-CS-A minimum multiple values
C01047 00181 ∂06-Jun-83 0111 FAHLMAN@CMU-CS-C Revenge of the Ballot
C01062 00182 ∂06-Jun-83 0136 ALAN@MIT-MC Revenge of the Ballot
C01063 00183 ∂06-Jun-83 0718 @USC-ECL,@MIT-MC:BSG%SCRC-TENEX@MIT-MC PARSE-INTEGER
C01064 00184 ∂06-Jun-83 0748 FAHLMAN@CMU-CS-C PARSE-INTEGER
C01066 00185 ∂06-Jun-83 0758 FAHLMAN@CMU-CS-C Ballot clarification
C01068 00186 ∂06-Jun-83 0953 RPG One last diddle to my error proposal
C01071 00187 ∂06-Jun-83 0953 RPG One last diddle to my error proposal
C01074 00188 ∂06-Jun-83 0954 RPG Finishing the Manual: Final Offer
C01084 00189 ∂06-Jun-83 0954 RPG
C01086 00190 ∂06-Jun-83 0954 RPG Offer
C01091 00191 ∂06-Jun-83 0955 RPG Offer
C01093 00192 ∂06-Jun-83 0948 @MIT-MC:DLW%SCRC-TENEX%MIT-MC@SU-DSN Re: Results of ballot A
C01095 00193 ∂06-Jun-83 0956 RPG Common Lisp Calls!
C01097 00194 ∂06-Jun-83 0956 RPG Common Lisp Manual
C01099 00195 ∂06-Jun-83 0957 RPG Comments on LASER.UPDATE
C01101 00196 ∂06-Jun-83 0957 RPG
C01103 00197 ∂06-Jun-83 0958 RPG [Moon%SCRC-TENEX: New setf writeup]
C01109 00198 ∂06-Jun-83 0956 RPG Follow up
C01119 00199 ∂06-Jun-83 0959 RPG Issues raised by MOON and DLW
C01128 00200 ∂06-Jun-83 0959 RPG Ok-by-me's
C01129 00201 ∂06-Jun-83 0959 RPG Issues raised by MOON and DLW
C01147 00202 ∂06-Jun-83 1000 RPG Changes to Laser edition for APPLYHOOK
C01154 00203 ∂06-Jun-83 1000 RPG Issues raised by MOON and DLW
C01161 00204 ∂06-Jun-83 1001 RPG Changes to Laser edition for APPLYHOOK
C01163 00205 ∂06-Jun-83 1002 RPG Issues raised by MOON and DLW
C01169 00206 ∂06-Jun-83 1002 RPG Non-ballot
C01177 00207 ∂06-Jun-83 1003 RPG cmuc:prva:<slisp.scl>laser.reply
C01199 00208 ∂06-Jun-83 1004 RPG :unspecific issues with pathnames
C01204 00209 ∂06-Jun-83 1004 RPG Non-ballot
C01213 00210 ∂06-Jun-83 1004 RPG Left and right parentheses
C01217 00211 ∂06-Jun-83 1005 RPG More polished DEFSETF
C01219 00212 ∂06-Jun-83 1005 RPG Package Chapter
C01221 00213 ∂06-Jun-83 1005 RPG More polished DEFSETF
C01223 00214 ∂06-Jun-83 1006 RPG [Mailer: Message of 29 May 83 18:40:49 EDT]
C01226 00215 ∂06-Jun-83 1006 RPG Laser.reply .reply .reply
C01234 00216 ∂06-Jun-83 1007 RPG Laser.reply .reply .reply
C01239 00217 ∂06-Jun-83 1014 RPG Laser.reply .reply .reply
C01243 00218 ∂06-Jun-83 1018 RPG Mnemonic for PISERIUC
C01245 00219 ∂06-Jun-83 1027 RPG Mnemonic for PISERIUC
C01247 00220 ∂06-Jun-83 1028 RPG MAPHASH
C01249 00221 ∂06-Jun-83 1029 RPG Mnemonic for PISERIUC
C01251 00222 ∂06-Jun-83 1029 RPG MAPHASH
C01252 00223 ∂06-Jun-83 1030 RPG Prose explaining floating point formats
C01254 00224 ∂06-Jun-83 1030 RPG Re: Mnemonic for PISERIUC
C01256 00225 ∂06-Jun-83 1030 RPG Obviosu effect
C01258 00226 ∂06-Jun-83 1031 RPG Mnemonic for PISERIUC
C01259 00227 ∂06-Jun-83 1036 RPG Laser.reply .reply .reply
C01262 00228 ∂06-Jun-83 1036 RPG Laser.reply .reply .reply
C01268 00229 ∂06-Jun-83 1036 RPG Prose explaining floating point formats
C01270 00230 ∂06-Jun-83 1037 RPG Left and right parentheses
C01273 00231 ∂06-Jun-83 1038 RPG MAPHASH
C01277 00232 ∂06-Jun-83 1038 RPG Ballot
C01280 00233 ∂06-Jun-83 1038 RPG Laser.reply .reply .reply
C01285 00234 ∂06-Jun-83 1038 RPG MAPHASH
C01287 00235 ∂06-Jun-83 1040 RPG Top-level forms
C01290 00236 ∂06-Jun-83 1041 RPG Top-level forms
C01294 00237 ∂06-Jun-83 1041 RPG Top-level forms
C01297 00238 ∂06-Jun-83 1042 RPG top-level forms
C01299 00239 ∂06-Jun-83 1042 RPG
C01301 00240 ∂06-Jun-83 1043 RPG top-level forms
C01304 00241 ∂06-Jun-83 1035 fateman%UCBKIM@Berkeley sqrt(-1)
C01307 00242 ∂06-Jun-83 1147 @MIT-MC:MOON@SCRC-TENEX Revenge of the Ballot
C01315 00243 ∂06-Jun-83 1230 RPG Top-level forms
C01318 00244 ∂06-Jun-83 1230 RPG Top-level forms
C01321 00245 ∂06-Jun-83 1230 RPG
C01328 00246 ∂06-Jun-83 1231 RPG [Mailer: Message of 5 Jun 83 15:33:40 EDT]
C01333 00247 ∂06-Jun-83 1231 RPG Arguments about arguments
C01338 00248 ∂06-Jun-83 1232 RPG Revenge of the Ballot
C01354 00249 ∂06-Jun-83 1316 ALAN@MIT-MC sqrt(-1)
C01358 00250 ∂06-Jun-83 1317 fateman%UCBKIM@Berkeley Re: sqrt(-1)
C01360 00251 ∂06-Jun-83 1534 HEDRICK@RUTGERS.ARPA Re: Revenge of the Ballot
C01364 00252 ∂06-Jun-83 1703 GSB@MIT-ML Revenge of the Ballot
C01367 00253 ∂06-Jun-83 1755 Walter.VanRoggen@CMU-CS-A Ballot B
C01369 00254 ∂06-Jun-83 1852 KMP@MIT-MC
C01376 00255 ∂06-Jun-83 1946 Guy.Steele@CMU-CS-A Multiple-value-revenge of the Ballot
C01379 00256 ∂06-Jun-83 2006 Guy.Steele@CMU-CS-A MANTISSA => SIGNIFICAND
C01381 00257 ∂06-Jun-83 2014 Guy.Steele@CMU-CS-A Re: sqrt(-1)
C01385 00258 ∂06-Jun-83 2100 FAHLMAN@CMU-CS-C Revenge of the Ballot
C01387 00259 ∂06-Jun-83 2226 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN NTH-VALUE
C01388 00260 ∂06-Jun-83 2301 GJC@MIT-MC
C01392 00261 ∂06-Jun-83 2343 GSB@MIT-ML [Re: revenge of the ballot, B7]
C01394 00262 ∂07-Jun-83 0013 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN [Re: revenge of the ballot, B7]
C01396 00263 ∂07-Jun-83 0146 KMP@MIT-MC
C01397 00264 ∂07-Jun-83 1430 @USC-ECL,@MIT-MC:BSG%SCRC-TENEX@MIT-MC DEFCONSTANT
C01401 00265 ∂07-Jun-83 1432 FAHLMAN@CMU-CS-C Testing
C01402 00266 ∂07-Jun-83 1431 FAHLMAN@CMU-CS-C Results of ballot B
C01412 00267 ∂07-Jun-83 1442 FAHLMAN@CMU-CS-C
C01415 00268 ∂07-Jun-83 1439 @USC-ECL,@MIT-MC:BSG%SCRC-TENEX@MIT-MC Pathname Conventions
C01417 00269 ∂07-Jun-83 1528 Walter.VanRoggen@CMU-CS-A Re: DEFCONSTANT
C01419 00270 ∂07-Jun-83 1934 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN Re: DEFCONSTANT
C01424 00271 ∂07-Jun-83 2241 FAHLMAN@CMU-CS-C DEFCONSTANT
C01428 00272 ∂07-Jun-83 2250 Guy.Steele@CMU-CS-A Re: DEFCONSTANT
C01430 00273 ∂07-Jun-83 2345 KMP@MIT-MC DEFCONSTANT, etc
C01434 00274 ∂08-Jun-83 0756 FAHLMAN@CMU-CS-C DEFCONSTANT
C01439 00275 ∂08-Jun-83 0950 Walter.VanRoggen@CMU-CS-A
C01442 00276 ∂08-Jun-83 0958 FAHLMAN@CMU-CS-C Loose ends
C01448 00277 ∂08-Jun-83 1142 @MIT-MC:BSG%SCRC-TENEX%MIT-MC@SU-DSN DEFCONSTANT
C01454 00278 ∂08-Jun-83 1213 @MIT-MC:MOON@SCRC-TENEX Loose ends
C01455 00279 ∂08-Jun-83 1235 @MIT-MC:BSG%SCRC-TENEX%MIT-MC@SU-DSN Re: DEFCONSTANT
C01458 00280 ∂08-Jun-83 1427 @USC-ECL,@MIT-MC:BSG%SCRC-TENEX@MIT-MC UNDEFCONSTANT
C01459 00281 ∂08-Jun-83 1602 @MIT-ML:Cassels%SCRC-TENEX%MIT-ML@SU-DSN Loose ends
C01463 00282 ∂08-Jun-83 1606 GSB@MIT-ML Loose ends
C01464 00283 ∂08-Jun-83 1809 GSB@MIT-ML defconstant, eval-when, etc.
C01467 00284 ∂08-Jun-83 2247 Guy.Steele@CMU-CS-A Re: DEFCONSTANT
C01468 00285 ∂09-Jun-83 1117 FISCHER@RUTGERS.ARPA Re: [Scott's message about EQ DEFCONSTANTs]
C01469 00286 ∂09-Jun-83 1656 @MIT-MC:MOON@SCRC-TENEX Re: [Scott's message about EQ DEFCONSTANTs]
C01472 00287 ∂09-Jun-83 2101 Guy.Steele@CMU-CS-A New meaning for "Flag Day"
C01475 00288 ∂10-Jun-83 1350 @MIT-MC:BSG%SCRC-TENEX%MIT-MC@SU-DSN Substitute-if
C01476 00289 ∂10-Jun-83 1855 Guy.Steele@CMU-CS-A Re: Substitute-if
C01478 00290 ∂10-Jun-83 1929 @MIT-MC:MOON@SCRC-TENEX Substitute-if
C01480 00291 ∂11-Jun-83 0527 FAHLMAN@CMU-CS-C DEFCONSTANT
C01482 00292 ∂11-Jun-83 1118 David.Dill@CMU-CS-A EQ-preservation
C01483 00293 ∂11-Jun-83 1505 FAHLMAN@CMU-CS-C EQ-preservation
C01485 00294 ∂11-Jun-83 2048 David.Dill@CMU-CS-A EQness of numbers
C01487 00295 ∂12-Jun-83 1151 @MIT-MC:MOON@SCRC-TENEX EQ-preservation
C01491 00296 ∂12-Jun-83 1227 FAHLMAN@CMU-CS-C DEFCONSTANT and EQ
C01495 00297 ∂12-Jun-83 1306 ALAN@MIT-MC DEFCONSTANT and EQ
C01497 00298 ∂12-Jun-83 1317 FAHLMAN@CMU-CS-C DEFCONSTANT and EQ
C01499 00299 ∂12-Jun-83 1336 @MIT-MC:BSG%SCRC-TENEX%MIT-MC@SU-DSN Re: DEFCONSTANT and EQ
C01500 00300 ∂12-Jun-83 1346 @MIT-MC:MOON@SCRC-TENEX DEFCONSTANT and EQ
C01502 00301 ∂12-Jun-83 1353 FAHLMAN@CMU-CS-C DEFCONSTANT and EQ
C01504 00302 ∂12-Jun-83 1357 FAHLMAN@CMU-CS-C DEFCONSTANT and EQ
C01506 00303 ∂12-Jun-83 1406 FAHLMAN@CMU-CS-C DEFCONSTANT and EQ
C01508 00304 ∂12-Jun-83 1502 RZ@MIT-MC Rational and complex numbers
C01515 00305 ∂12-Jun-83 1622 GSB@MIT-ML EQL and byte specifiers
C01516 00306 ∂12-Jun-83 1656 @MIT-MC:MOON@SCRC-TENEX Rational and complex numbers
C01517 00307 ∂12-Jun-83 1905 RZ@MIT-MC Rational and complex numbers
C01520 00308 ∂12-Jun-83 1931 FAHLMAN@CMU-CS-C New built-in package
C01522 00309 ∂12-Jun-83 2053 Guy.Steele@CMU-CS-A Re: Rational and complex numbers
C01524 00310 ∂13-Jun-83 0629 @MIT-MC:BSG%SCRC-TENEX%MIT-MC@SU-DSN Substitute-if
C01527 00311 ∂14-Jun-83 0606 MLB@SPA-NIMBUS New built-in package Strikes Back.
C01530 00312 ∂14-Jun-83 1449 @USC-ECL,@MIT-XX:BSG@SCRC-TENEX Happy Flag Day
C01533 00313 ∂14-Jun-83 2011 FAHLMAN@CMU-CS-C Happy Flag Day
C01535 00314 ∂14-Jun-83 2027 KMP@MIT-MC
C01536 00315 ∂14-Jun-83 2054 @MIT-MC:BSG%SCRC-TENEX%MIT-MC@SU-DSN Re: Happy Flag Day
C01539 00316 ∂14-Jun-83 2106 Guy.Steele@CMU-CS-A BONG BONG BONG BONG BONG BONG BONG BONG BONG BONG BONG BONG
C01541 00317 ∂14-Jun-83 2107 Guy.Steele@CMU-CS-A Darn!
C01542 00318 ∂15-Jun-83 0530 @MIT-ML:BSG%SCRC-TENEX%MIT-ML@SU-DSN Re: Happy Flag Day
C01545 00319 ∂15-Jun-83 0934 HEDRICK@RUTGERS.ARPA consistency
C01547 00320 ∂15-Jun-83 0938 Moon@SCRC-TENEX Re: Happy Flag Day
C01549 00321 ∂15-Jun-83 0937 Moon@SCRC-TENEX DEFCONSTANT and EQ
C01562 00322 ∂16-Jun-83 0946 RPG consistency
C01568 00323 ∂16-Jun-83 0946 RPG DEFSETF
C01573 00324 ∂16-Jun-83 0947 RPG Package chapter updated
C01576 00325 ∂16-Jun-83 0949 RPG Package chapter updated
C01579 00326 ∂16-Jun-83 1119 Cassels@SCRC-TENEX floating-point format
C01583 00327 ∂16-Jun-83 1132 @MIT-MC:MOON@SCRC-TENEX floating-point format
C01584 00328 ∂16-Jun-83 1402 @MIT-MC:kmp@MIT-MC Rounding on output
C01586 00329 ∂16-Jun-83 1551 @MIT-MC:Cassels%SCRC-TENEX%MIT-MC@SU-DSN Rounding on output
C01590 00330 ∂16-Jun-83 1604 RPG Common Lisp Ontology
C01592 00331 ∂16-Jun-83 1759 FAHLMAN@CMU-CS-C Rounding on output
C01594 00332 ∂16-Jun-83 2047 Guy.Steele@CMU-CS-A Re: Rounding on output
C01596 00333 ∂17-Jun-83 1623 @MIT-MC:Cassels%SCRC-TENEX%MIT-MC@SU-DSN Rounding on output
C01599 00334 ∂18-Jun-83 2053 FAHLMAN@CMU-CS-C MEMBER
C01604 00335 ∂18-Jun-83 2158 RPG Funargs
C01609 00336 ∂19-Jun-83 1108 @MIT-MC:RMS%MIT-OZ%MIT-MC@SU-DSN MEMBER, etc.
C01613 00337 ∂19-Jun-83 1340 @MIT-MC:RMS%MIT-OZ%MIT-MC@SU-DSN
C01614 00338 ∂19-Jun-83 1342 HEDRICK@RUTGERS.ARPA Re: MEMBER
C01616 00339 ∂19-Jun-83 1411 FAHLMAN@CMU-CS-C
C01617 00340 ∂19-Jun-83 1452 @MIT-MC:RMS@MIT-OZ Function MEMBER to be changed?
C01619 00341 ∂19-Jun-83 1558 KMP@MIT-MC MEMBER, MEMBERP
C01624 00342 ∂19-Jun-83 1803 FAHLMAN@CMU-CS-C MEMBER, etc.
C01632 00343 ∂20-Jun-83 0914 RPG Funargs
C01636 00344 ∂20-Jun-83 0915 RPG MEMBER
C01641 00345 ∂20-Jun-83 0915 RPG Funargs
C01643 00346 ∂20-Jun-83 0915 RPG Funargs
C01649 00347 ∂20-Jun-83 0915 RPG Function MEMBER to be changed?
C01651 00348 ∂20-Jun-83 0916 RPG RMS's phone call
C01662 00349 ∂20-Jun-83 0916 RPG Funargs
C01664 00350 ∂20-Jun-83 0916 RPG RMS's phone call
C01667 00351 ∂20-Jun-83 0916 RPG Function MEMBER to be changed?
C01668 00352 ∂20-Jun-83 0917 RPG Upward/downward funarg
C01671 00353 ∂20-Jun-83 0917 RPG MEMBER, etc.
C01675 00354 ∂20-Jun-83 0917 RPG Change in MEMBER, etc.
C01676 00355 ∂20-Jun-83 0917 RPG RMS's phone call
C01682 00356 ∂20-Jun-83 0917 RPG RMS's phone call
C01684 00357 ∂20-Jun-83 0918 RPG
C01685 00358 ∂20-Jun-83 0919 RPG Changes to MEMBER, ASSOC, etc.
C01691 00359 ∂20-Jun-83 0919 RPG Stallman
C01695 00360 ∂20-Jun-83 0920 RPG KMP's message
C01698 00361 ∂20-Jun-83 0920 RPG Destructuring &aux ?
C01701 00362 ∂20-Jun-83 0920 RPG Destructuring &aux ?
C01703 00363 ∂20-Jun-83 1422 @USC-ECL,@MIT-MC:BSG%SCRC-TENEX@MIT-MC keywordp
C01705 00364 ∂20-Jun-83 2030 RPG RMS's phone call
C01708 00365 ∂20-Jun-83 2032 RPG want to argue from experience?
C01710 00366 ∂20-Jun-83 2054 @MIT-MC:RMS%MIT-OZ%MIT-MC@SU-DSN
C01712 00367 ∂20-Jun-83 2132 RPG RMS's Poll
C01714 00368 ∂21-Jun-83 1612 DLW@SCRC-TENEX OPEN for :OUTPUT with version :NEWEST
C01716 00369 ∂21-Jun-83 2221 FAHLMAN@CMU-CS-C Memberp
C01719 00370 ∂21-Jun-83 2250 @MIT-MC:RMS%MIT-OZ%MIT-MC@SU-DSN My poll of Lisp users
C01725 00371 ∂21-Jun-83 2259 RPG Unable to deliver mail
C01728 00372 ∂21-Jun-83 2259 RPG Common LISP Nonsense
C01730 00373 ∂21-Jun-83 2320 RPG Common Lisp
C01733 00374 ∂22-Jun-83 0015 RPG Manual
C01735 00375 ∂22-Jun-83 0045 FAHLMAN@CMU-CS-C MEMBER
C01740 00376 ∂22-Jun-83 0059 KMP@MIT-MC OPEN for :OUTPUT with version :NEWEST
C01744 00377 ∂22-Jun-83 0347 @MIT-MC:DLW%SCRC-TENEX%MIT-MC@SU-DSN Re: OPEN for :OUTPUT with version :NEWEST
C01747 00378 ∂22-Jun-83 0430 RAM@CMU-CS-C OPEN for :OUTPUT with version :NEWEST
C01750 00379 ∂22-Jun-83 0828 RZ@MIT-MC Rational and complex numbers
C01753 00380 ∂22-Jun-83 0839 @MIT-MC:DLW%SCRC-TENEX%MIT-MC@SU-DSN OPEN for :OUTPUT with version :NEWEST
C01758 00381 ∂22-Jun-83 1429 RPG Common Lisp support
C01759 00382 ∂22-Jun-83 2310 HEDRICK@RUTGERS.ARPA Re: Memberp
C01762 00383 ∂23-Jun-83 1110 RPG Re: Clarification of closures
C01771 00384 ∂23-Jun-83 1453 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN [RZ at MC: Rational and complex numbers]
C01782 00385 ∂24-Jun-83 0809 RZ@MIT-MC [RZ at MC: Rational and complex numbers]
C01784 00386 ∂25-Jun-83 0922 FAHLMAN@CMU-CS-C &whole
C01785 00387 ∂25-Jun-83 1812 RPG Closures
C01786 00388 ∂29-Jun-83 1033 RPG Okay, guys, this is serious
C01791 00389 ∂29-Jun-83 1035 RPG Re: Clarification of closures
C01793 00390 ∂29-Jun-83 1036 RPG Re: Clarification of closures
C01802 00391 ∂29-Jun-83 1036 RPG Clarification of closures
C01804 00392 ∂29-Jun-83 1037 RPG Clarification of closures
C01806 00393 ∂29-Jun-83 1038 RPG Clarification of closures
C01809 00394 ∂29-Jun-83 1108 RPG Seriosity
C01811 00395 ∂29-Jun-83 1401 RPG Seriosity
C01815 00396 ∂30-Jun-83 1129 Rees@YALE misc. stuff
C01819 00397 ∂01-Jul-83 0047 FAHLMAN@CMU-CS-C &optional args in DEFMACRO
C01822 00398 ∂01-Jul-83 0117 @MIT-MC:MOON@SCRC-TENEX &optional args in DEFMACRO
C01824 00399 ∂01-Jul-83 0131 ALAN@MIT-MC &optional args in DEFMACRO
C01826 00400 ∂01-Jul-83 1216 GJC@MIT-ML
C01827 00401 ∂01-Jul-83 1524 FAHLMAN@CMU-CS-C defmacro &optional
C01829 00402 ∂02-Jul-83 1518 ALAN@MIT-MC +0.0 vs. -0.0 vs. EQL
C01834 00403 ∂02-Jul-83 2249 RPG Seriosity
C01835 00404 ∂02-Jul-83 2249 RPG Seriosity
C01837 00405 ∂02-Jul-83 2312 @MIT-MC:DLW@SCRC-TENEX +0.0 vs. -0.0 vs. EQL
C01838 00406 ∂03-Jul-83 1154 KMP@MIT-MC (EQL -0.0 +0.0) => NIL
C01840 00407 ∂04-Jul-83 0954 @MIT-MC:DLW%SCRC-TENEX%MIT-MC@SU-DSN misc. stuff
C01844 00408 ∂04-Jul-83 1931 fateman%UCBKIM@Berkeley Re: +0.0 vs. -0.0 vs. EQL
C01846 00409 ∂05-Jul-83 1553 GJC@MIT-MC Who is implementing CL on the CDC 6400?
C01847 00410 ∂05-Jul-83 1957 RPG MEMBERP et al
C01849 00411 ∂06-Jul-83 1123 Rees@YALE more misc. stuff
C01852 00412 ∂06-Jul-83 1151 CELLIO@CMU-CS-C.ARPA Re: more misc. stuff
C01854 00413 ∂06-Jul-83 1337 @MIT-MC:MOON@SCRC-TENEX more misc. stuff
C01856 00414 ∂08-Jul-83 2316 RPG Destructuring &aux ?
C01858 00415 ∂08-Jul-83 2317 RPG Seriosity
C01862 00416 ∂08-Jul-83 2319 RPG Seriosity
C01866 00417 ∂08-Jul-83 2322 RPG Pathname query
C01868 00418 ∂08-Jul-83 2323 RPG Pathname query
C01871 00419 ∂08-Jul-83 2325 RPG Request for clarification of destructuring DEFMACRO
C01875 00420 ∂08-Jul-83 2326 RPG Request for clarification of destructuring DEFMACRO
C01877 00421 ∂11-Jul-83 0942 RPG Request for clarification of destructuring DEFMACRO
C01879 00422 ∂11-Jul-83 0943 RPG Request for clarification of destructuring DEFMACRO
C01882 00423 ∂11-Jul-83 0943 RPG Request for clarification of destructuring DEFMACRO
C01884 00424 ∂11-Jul-83 0944 RPG Request for clarification of destructuring DEFMACRO
C01888 00425 ∂11-Jul-83 1736 RPG [COMSAT: Msg of Saturday, 9 July 1983 17:40 EDT] I just gotta try again.
C01890 00426 ∂12-Jul-83 1449 @MIT-MC:hes%VIXEN%MIT-MC@SU-DSN function specs
C01893 00427 ∂12-Jul-83 1820 Masinter.PA@PARC-MAXC.ARPA Re: function specs
C01895 00428 ∂12-Jul-83 1923 @SU-SCORE.ARPA,@MIT-XX:BENSON@SPA-NIMBUS function specs
C01899 00429 ∂12-Jul-83 1923 FAHLMAN@CMU-CS-C.ARPA function specs
C01905 00430 ∂12-Jul-83 1945 KMP@MIT-MC Historical Footnote
C01909 00431 ∂13-Jul-83 2008 EAK@MIT-MC function specs
C01910 00432 ∂14-Jul-83 0743 @USC-ECL,@MIT-MC:BSG%SCRC@MIT-MC function specs
C01913 00433 ∂14-Jul-83 1233 @USC-ECL,@MIT-XX:BENSON@SPA-NIMBUS Top level forms in a compiled file
C01919 00434 ∂14-Jul-83 1324 @USC-ECL,@MIT-XX:BENSON@SPA-NIMBUS Top level forms in a compiled file
C01925 00435 ∂14-Jul-83 1351 @USC-ECL,@MIT-MC:BSG%SCRC@MIT-MC Top level forms in a compiled file
C01929 00436 ∂14-Jul-83 1442 KMP@MIT-MC
C01932 00437 ∂14-Jul-83 2001 @MIT-MC:BENSON@SPA-NIMBUS Compiling top level forms
C01935 00438 ∂14-Jul-83 2012 Guy.Steele@CMU-CS-A Top-level forms
C01936 00439 ∂14-Jul-83 2020 @USC-ECL,@MIT-MC:BENSON@SPA-NIMBUS Top level forms in a compiled file
C01939 00440 ∂14-Jul-83 2027 JONL.PA@PARC-MAXC.ARPA Re: Top-level forms
C01941 00441 ∂16-Jul-83 1407 KMP@MIT-MC Top level forms in a compiled file
C01945 00442 ∂17-Jul-83 0901 @MIT-MC:DLW%SCRC%MIT-MC@SU-DSN Top level forms in a compiled file
C01947 00443 ∂20-Jul-83 2032 @USC-ISIB,DDYER@USC-ISIB list of lisps
C01948 00444 ∂25-Jul-83 1235 @MIT-MC:Server@SPA-NIMBUS Failed mail
C01953 00445 ∂26-Jul-83 2227 Guy.Steele@CMU-CS-A Re: small snafu in LASER edn.
C01954 00446 ∂28-Jul-83 0952 GBROWN@DEC-MARLBORO.ARPA ERROR SIGNALLING FUNCTIONS
C01962 00447 ∂28-Jul-83 1215 @MIT-MC:DLW%SCRC-TENEX%MIT-MC@SU-DSN ERROR SIGNALLING FUNCTIONS
C01967 00448 ∂28-Jul-83 1217 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN ERROR SIGNALLING FUNCTIONS
C01971 ENDMK
C⊗;
∂17-May-83 2320 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN Break
Received: from MIT-MC by SU-AI with TCP/SMTP; 17 May 83 23:20:16 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Wed 18-May-83 02:11:07-EDT
Date: Wednesday, 18 May 1983, 02:09-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Break
To: common-lisp@su-ai
In-reply-to: The message of 17 May 83 22:16-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: Tue, 17 May 1983 22:16 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
How about if we just say that BREAK enters the debugger or a recursive
read/eval/print loop at the implementation's discretion?
Okay
∂18-May-83 0004 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN Conservation of nits
Received: from MIT-MC by SU-AI with TCP/SMTP; 18 May 83 00:03:46 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Wed 18-May-83 03:04:58-EDT
Date: Wednesday, 18 May 1983, 03:03-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Conservation of nits
To: common-lisp@su-ai
In-reply-to: The message of 18 May 83 00:08-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: Wed, 18 May 1983 00:08 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
From: Moon
I hope you realize that IN-PACKAGE is incompatible with incremental
re-compilation of portions of files (after editing them), a Lisp machine
productivity feature that users are uniformly enthusiastic about. I
would think that this would be something that Spice Lisp would definitely
want, too, once you have a compiler that runs natively in your Lisp.
I'm not sure yet whether we will strongly discourage people from using
IN-PACKAGE, or whether we will provide a kludgey way for the editor to
know that it must parse the beginning of the file looking for IN-PACKAGE
in order to determine in what package to read forms from the file.
I don't completely understand this. I looked for incremental
compilation in the Confederate edition of the Chine Nual and couldn't
find anything about it. What exactly do you folks do? I would have
assumed that if you do incremental re-compilation on an ASCII file, you
take some notice of the -*-Package:foo-*- business, no? IN-PACKAGE
would have the same set of problems as that. I would hate to have you
tell users not to use IN-PACKAGE. Do you have a specific proposal?
The Chine Nual doesn't document the editor. Incremental compilation =
designate some portion of the buffer in the editor (in the simplest case
it's the top-level form surrounding the editor cursor) and compile it
putting the results into the current environment. You can also just
read/eval/print it. To do this the editor needs to know the base, readtable,
and package required to read the text (it also needs to know what language
it's in, but that's a different story). The way we tell the editor this
information is to put it all in the file attribute line, which is the first
non-blank line in the file and contains the characters "-*-". The important
point about this is not the particular representation of this information,
but the fact that it is the same for everything in the file. When recompiling
something halfway down the file, you don't need to read everything from the
beginning of the file up to there to find out what package (etc.) is needed
to read the one form being compiled.
The only thing that is important about the particular representation of
the information is that you can find it, or determine that it is absent,
without reading through the whole file, and in fact there is a general
facility for dealing with these file attribute lines, used by the
editor, the compiler, the loader, and any other programs that care.
Doing it with Lisp forms that you evaluate, such as IN-PACKAGE, works
for the compiler and the loader, but for other programs (the editor is
an example) whose business is not to evaluate Lisp forms it doesn't fit
in so smoothly.
So one issue is allowing the package (etc.) to change in the middle of a
file. This seems of little worth to me, so I doubt we will make any
effort to support incremental compilation of files that do this. We
will of course support non-incremental compilation and loading of such
files if Common Lisp allows them. The other issue is whether we want
(not in Common Lisp, but in our own Lisp machine user interface) to
introduce a new syntax for saying what package (etc.) a file is in, when
we already have one. Probably we will just say that you put the
information in both places if you want your file to be incrementally
compilable and you want it to work in other Common Lisp implementations.
My concern is not that we (Symbolics) can't accept IN-PACKAGE, I was more
trying to point out that you (Spice) might be backing yourselves into a corner
without realizing it, by adopting a style of programming that is inimicable
to incremental compilation.
The writeup doesn't say why certain functions should be used at top
level. One reason is that if changes are being made to *package* with
the expectation that they will affect how forms later in the file are
read, then those changes had better happen at compile time before
further forms are read from the file. The other reason is that in many
implementations the output from the compiler is designed so that the
loader can look symbols up once, rather having to call INTERN every time
a symbol is referenced. This means that the compiler must know when the
package state is changing (i.e. the read-read consistency rule doesn't
apply). It would probably be best to include an Implementation Note
pointing out the restrictions this places on the compiler/loader
implementation: the compiler may not read the whole file before compiling
any of it (as the Lisp machine used to do in order to improve virtual
memory locality); the loader may not do all its INTERNs before evaling
any of the top-level forms (as Multics Maclisp does).
The writeup should say explicitly which functions get an automatic
(eval-when (compile) ...) wrapped around them when they are seen at
top level by the compiler. The example at the end is assuming this
implicitly.
Well, both of the above comments assume that the compiler represents
symbols and their packages internally just by reading them into the
right package. Certainly the compiler has to keep track of what
packages the various symbols want to end up in, but this might be done
by some more complex mechanism if the compiler wanted to keep its guts
somewhat separate from the stuff it is reading. I'll see if I can say
something sufficient about this without over-specifying the mechanism.
I don't think macros can reasonably run at compile time if the compiler
doesn't represent symbols in the code to be compiled as symbols. Your
last sentence above sounds like the right thing.
I can find no justification in the previous discussion for the suddenly
introduced restriction that EXPORT and UNEXPORT are not allowed in
packages that have been USE-PACKAGE'd, unless this is a Solomonian
attempt to resolve the copy vs reference issue. If this is trying to
deal with the case of exporting a symbol too late, after someone who
thought they were getting it via USE-PACKAGE made an internal symbol
instead, the naming conflict checks I suggested earlier detect this and
are able to tell you exactly what happened. If this is trying to deal
with the case where exporting a new symbol, that people using
USE-PACKAGE didn't expect to see exported, causes what was expected to
be two distinct symbols, internal in different packages, to become one
(external) symbol, it doesn't deal with it. That can just as well
happen if all the EXPORTs are done before all the USE-PACKAGEs, and is
basically indetectable. This screw case is really a lot like someone
changing what a function does without telling everyone who uses it.
I was just trying to do something simple and safe that might end the
debate. I figured that I could get this "package locking" rule right on
the first try, and that some tricky rule to signal an error only in the
case of a conflict with some symbol in the inferior package that is not
on that package's shadow list would lead to N more rounds of revision.
You seem to understand this better than I do. How about if you propose
the exact wording for the error-checking rule you would like to see here
(both for EXPORT and for UNEXPORT)? That would be the quickest way to
converge, I think.
Okay. But not in this message, I'm too tired to write coherently. Tomorrow.
Just out of curiosity, why in the world would anyone compile an INIT
file?
To make it load faster, or to make the dozens of functions defined in it
run faster. You should see the init files of some of our people!
∂18-May-83 1030 @MIT-MC:MOON@SCRC-TENEX revised BREAK writeup
Received: from MIT-MC by SU-AI with TCP/SMTP; 18 May 83 10:29:55 PDT
Date: Wednesday, 18 May 1983 13:30-EDT
From: MOON at SCRC-TENEX
To: Common-Lisp at su-ai
Subject:revised BREAK writeup
BREAK &optional format-string &rest args
Print the message and go directly into the debugger, without allowing
any possibility of interception by programmed error-handling facilities.
There aren't any error-handling facilities in Common Lisp, but there
might be in particular implementations, and there will be in Common Lisp
in the future. When continued, BREAK returns NIL. It is permissible to
call BREAK with no arguments; it will supply some default message.
BREAK is presumed to be used as a way of inserting temporary debugging
"breakpoints" in a program, not as a way of signalling errors. Thus
continuing from a BREAK would never do anything special, and it does not
take the second FORMAT control-string argument that CERROR takes. This
and the lack of any possibility of interception by programmed
error-handling are the only program-visible differences between BREAK
and CERROR. The interactive debugger may choose to display them
differently, for instance a CERROR's message might be prefixed with
"Error:" and a BREAK's message prefixed with "Break:". This depends on
the user-interface style of the particular implementation. A particular
implementation may choose, according to its own style and needs, to go
into a different debugger when BREAK is called than when an error occurs.
For example, it might go into a plain read-eval-print loop identical to
the top-level one except for the provision of a "continue" command that
causes BREAK to return NIL.
Compatibility note: Maclisp's BREAK takes two optional arguments. The
first would be a string if Maclisp had strings. The second is a boolean
value specifying whether BREAK should break or return immediately. In
Common Lisp one makes a BREAK conditional by putting it inside a conditional
form such as WHEN or UNLESS.
∂18-May-83 1344 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN writeup on name conflicts
Received: from MIT-MC by SU-AI with TCP/SMTP; 18 May 83 13:44:12 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Wed 18-May-83 16:47:27-EDT
Date: Wednesday, 18 May 1983, 16:45-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: writeup on name conflicts
To: Common-Lisp@su-ai
@section[Name Conflicts]
A fundamental invariant of the package system is that within one package
any particular name can only refer to one symbol. A @i[name conflict]
is said to occur when there is more than one candidate symbol and it is
not obvious which one to choose. If the system does not always choose
the same way, the read-read consistency rule would be violated. For
example, some programs or data might have been read in under a certain
mapping of the name to a symbol. If the mapping changes to a different
symbol, then additional programs or data are read, the two programs will
not access the same symbol even though they use the same name. Even if
the system did always choose the same way, a name conflict is likely to
result in a different mapping from names to symbols than was expected by
the user, causing programs to execute incorrectly. Therefore, any time
a name conflict occurs, an error is signalled. The user may continue
from the error and tell the package system how to resolve the conflict.
Note that if the same symbol is accessible to a package through more than
one path, for instance as an external of more than one package, or both
through inheritance and through direct presence in the package, there is
no name conflict. Name conflicts only occur between distinct symbols with
the same name.
The creator of a package can tell the system in advance how to resolve a
name conflict through the use of @i[shadowing]. Every package has a
list of shadowing symbols. A shadowing symbol takes precedence over any
other symbol of the same name that would otherwise be accessible to the
package. A name conflict involving a shadowing symbol is always
resolved in favor of the shadowing symbol, without signalling an error
(except for one exception involving @b[import] described below). The
functions @b[shadow] and @b[shadowing-import] may be used to declare
shadowing symbols.
Name conflicts are detected when they become possible, i.e. when the
package structure is altered. There is no need to check for name
conflicts during every name lookup.
The functions @b[use-package], @b[import], and @b[export] check for name
conflicts. @b[use-package] makes the external symbols of the package
being used accessible to the using package; each of these symbols is
checked for name conflicts with the symbols already accessible.
@b[import] adds a single symbol to the internals of a package, checking
for a name conflict with an existing symbol either present in the
package or accessible to it. @b[import] signals an error even if there
is a name conflict with a shadowing symbol, because two explicit
directives from the user are inconsistent. @b[export] makes a single
symbol accessible to all the packages that use the package from which
the symbol is exported. All of these packages are checked for
name conflicts: @b[(export @i[s] @i[p])] does
@b[(find-symbol (symbol-name @i[s]) @i[q])] for each package @i[q]
in @b[(package-used-by-list @i[p])]. Note that in the usual case of
an @b[export] during the initial definition of a package, the
@b[package-used-by-list] will be @b[nil] and the name conflict checking
will take no time.
@b[intern] does not need to do any name-conflict checking, because it
never creates a new symbol if there is already an accessible symbol with
the name given.
@b[shadow] and @b[shadowing-import] never signal a name-conflict error,
because by calling these functions the user has specified how any
possible conflict is to be resolved. @b[shadow] does name-conflict
checking to the extent that it checks whether a distinct existing symbol with
the specified name is accessible, and if so whether it is directly
present in the package or inherited; in the latter case a new symbol
is created to shadow it. @b[shadowing-import] does name-conflict
checking to the extent that it checks whether a distinct existing
symbol with the same name is accessible; if so it is shadowed by
the new symbol, which implies that it must be @b[unintern]ed if it was
directly present in the package.
@b[unuse-package], @b[unexport], and @b[unintern] (when the symbol being
@b[unintern]ed is not a shadowing symbol) do not need to do any
name-conflict checking, because they only remove symbols from a package;
they do not make any new symbols accessible.
@b[unintern] of a shadowing symbol can uncover a name conflict that had
previously been resolved by the shadowing. If package A uses packages
B and C, A contains a shadowing symbol @b[x], and B and C each contain external
symbols named @b[x], then @b[unintern]ing @b[x] from A will reveal a name
conflict between @b[b:x] and @b[c:x] if those two symbols are distinct.
In this case @b[unintern] will signal an error.
Aborting from a name-conflict error leaves the original symbol accessible.
Package functions always signal name-conflict errors before making any
change to the package structure. Note: when multiple changes are to be
made, for example when @b[export] is given a list of symbols, it is legal
for each change to be processed separately, so that aborting from a name
conflict caused by the second symbol in the list will not unexport the
first symbol in the list. However, aborting from a name conflict error
caused by @b[export] of a single symbol will not leave that symbol accessible
to some packages and inaccessible to others; @b[export]
appears as an atomic operation.
Continuing from a name-conflict error should offer the user a chance to
resolve the name conflict in favor of either of the candidates. The
package structure should be altered to reflect the resolution of the
name conflict, via @b[shadowing-import], @b[unintern], or @b[unexport].
A name conflict in @b[use-package] between a symbol directly present in the
using package and an external symbol of the used package may be resolved
in favor of the first symbol by making it a shadowing symbol, or in favor
of the second symbol by @b[unintern]ing the first symbol from the using
package. The latter resolution is dangerous if the symbol to be
@b[unintern]ed is an external symbol of the using package since it
will cease to be an external symbol.
A name conflict in @b[use-package] between two external symbols inherited
by the using package from other packages may be resolved in favor of
either symbol by importing it into the using package and making it a
shadowing symbol.
A name conflict in @b[export] between the symbol being exported and a
symbol already present in a package that would inherit the
newly-exported symbol may be resolved in favor of the exported symbol
by @b[unintern]ing the other one, or in favor of the already-present
symbol by making it a shadowing symbol.
A name conflict in @b[export] or @b[unintern] due to a package
inheriting two distinct symbols with the same name from two other
packages may be resolved in favor of either symbol by importing it into
the using package and making it a shadowing symbol, just as with
@b[use-package].
A name conflict in @b[import] between the symbol being imported and a
symbol inherited from some other package may be resolved in favor of the
symbol being imported by making it a shadowing symbol, or in favor
of the symbol already accessible by not doing the @b[import]. A
name conflict in @b[import] with a symbol already present in the
package may be resolved by @b[unintern]ing that symbol, or by not
doing the @b[import].
Good user-interface style dictates that @b[use-package] and @b[export],
which can cause many name conflicts simultaneously, first check for
all of the name conflicts before presenting any of them to the user.
The user may then choose to resolve all of them wholesale, or to resolve
each of them individually, requiring a lot of interaction but permitting
different conflicts to be resolved different ways.
Some implementations will have other ways of resolving name conflicts to
offer. For instance, if the symbols that conflict are not being used as
objects, but only as names for functions, it may be possible to "merge"
the two symbols by putting the function definition onto both symbols.
References to either symbol for purposes of calling a function would be
equivalent. A similar merging operation can be done for variable values
and for things stored on the property list. On the Lisp machine one can
also @i[forward] the value, function, and property cells so that future
changes to either symbol will propagate to the other one. Some other
implementations are able to do this with value cells, but not with
property lists. Only the user can know whether this way of resolving
a name conflict is adequate, i.e. the fact that there are two non-@b[eq]
symbols with the same name doesn't affect the correct operation of
his program. The value of offering symbol-merging as a way of resolving
name conflicts is that it can avoid the need to throw away the whole
Lisp world and start over, after correcting the package-definition forms
that caused the error.
∂18-May-83 2123 FAHLMAN@CMU-CS-C Maphash
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 18 May 83 21:22:49 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 19 May 83 00:23:20 EDT
Date: Thu, 19 May 1983 00:23 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: common-lisp@su-ai
Cc: les@CMU-CS-C
Subject: Maphash
One of my hackers has just noticed that we still map over the elements
of a hashtable with MAPHASH, while we have changed most similar forms to
DO-mumble, as in DO-SYMBOLS, etc. Since MAPHASH returns NIL, there is
no elegant way to turn the contents of a hashtable into a list. What
would people think of flushing MAPHASH and replacing it with
DO-HASH ?
-- Scott
∂18-May-83 2148 FAHLMAN@CMU-CS-C Revenge of the Packages
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 18 May 83 21:46:45 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 19 May 83 00:47:40 EDT
Date: Thu, 19 May 1983 00:47 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: common-lisp@su-ai
Subject: Revenge of the Packages
Minor cleanup and incorporation of Moon's treatise on name conflicts.
***************************************************************************
@chapter [Packages]
@section [Overview]
One problem with earlier Lisp systems is the use of a single name space
for all symbols. In large Lisp systems, with modules written by many
different programmers, accidental name collisions become a serious
problem. Common Lisp addresses this problem through the @i[package
system], derived from an earlier package system developed for Lisp
Machine Lisp. In addition to preventing name-space conflicts, the
package system makes the modular structure of large Lisp systems more
explicit.
A @i[package] is a data structure that establishes a mapping from print
names (strings) to symbols. The package thus replaces the ``oblist'' or
``obarray'' machinery of earlier Lisp systems. At any given time one
package is current, and this package is used by the reader in
translating strings into symbols. The current package is always the
value of the global variable @b[*package*]. It is possible to refer to
symbols in packages other than the current one through the use of
@i[package qualifiers] in the symbol reference. For example @b[foo:bar]
refers to the symbol whose name is @b[bar] in the package whose name is
@b[foo].
The string-to-symbol mappings available in a given package are divided
into two classes, @i[external] and @i[internal]. We refer to the
symbols accessible via these mappings as being @i[external] and
@i[internal] symbols of the package in question, though really it is the
mappings that are different and not the symbols themselves. Within a
given package, a name refers to one symbol or to none; if it does refer
to a symbol, that symbol is either external or internal in that
package, but not both.
External symbols are part of the package's public interface to other
packages. These are supposed to be chosen with some care and are
advertised to users of the package. Internal symbols are for internal
use only, and these symbols are normally hidden from other packages.
Most symbols are created as internal symbols; they become external only
if they appear explicitly in some package's @b[export] command.
A symbol may appear in many packages. It will always have the same
print name wherever it appears, but it may be external in one package
and internal in another. A name may refer to different symbols in
different packages.
Packages may be built up in layers. From the point of view of a
package's user, the package is a single collection of mappings from
strings into internal and external symbols. However, some of these
mappings may be established within the package itself, while other
mappings are inherited from other packages via the @b[use-package]
construct. (The mechansims responsible for this inheritance are
described below.) In what follows, we will refer to a symbol as being
"accessible" in a package if it can be referred to in that package
without a qualifier, regardless of whether the mapping occurs within
that package or via inheirtance; we will refer to a symbol as being
"present" in a package if the mapping is in the package itself and is
not inherited from somewhere else.
@section [Consistency Rules]
Package-related bugs can be very subtle and confusing: things are not
what they appear to be. The Common Lisp package system is designed with
a number of safety features to prevent most of the common bugs that
would otherwise occur in normal use. This may seem over-protective, but
experience with earlier package systems has shown that such safety
features are needed.
In dealing with the package system, it is useful to keep in mind the
following consistency rules, which remain in force as long as the value
of @b[*package*] is not changed by the user or his code:
@begin [itemize]
@b[Read-Read consistency:] Reading the same print name always gets you
the same (EQ) symbol.
@b[Print-Read consistency:] An interned symbol always prints as a
sequence of characters which, when read back in, yields the same (EQ)
symbol.
@b[Print-Print consistency:] If two interned symbols are not EQ, then
their printed representations will not be the same sequence of
characters.
@end [itemize]
These consistency rules remain true in spite of any amount of implicit
interning caused by typing in Lisp forms, loading files, etc. This has
the important implication that results are reproducible regardless of
the order of loading files or the exact history of what symbols were
typed in when. The rules can only be violated by explicit action:
changing the value of @b[*package*], forcing some action by continuing
from an error, or calling one of the ``dangerous'' functions:
@b[unintern], @b[shadow], or @b[shadowing-import].
@section [Package Names]
Each package has a name (a string) and perhaps some nicknames. These
are assigned when the package is created, though they can be changed
later. A package's name should be something long and self-explanatory
like "editor"; there might be a nickname that is shorter and easier to
type, like "ed". Package name strings retain whatever mixture of upper
and lower case characters the user supplies, but the translation from
names to packages is case-insensitive, so users can generally refer to
packages without worrying about case.
There is a single name space for packages. The function
@b[find-package] translates a package-name or nickname into the
associated package. The function @b[package-name] returns the name of a
package. The function @b[package-nicknames] returns a list of all
nicknames for a package. The function @b[rename-package] removes a
package's current name and nicknames and replaces them with new ones
specified by the user. Package renaming is occasionally useful when, for
development purposes, it is desirable to load two versions of a package
into the same Lisp. We can load one, rename it, and then load the
other, without getting a lot of name conflicts.
@section [Translating Strings to Symbols]
The value of the special variable @b[*package*] must always be a package
object (not a name). This is referred to as the @i[current package].
When the Lisp reader has, by parsing, obtained a string of characters
thought to name a symbol, that name is looked up in the current package.
This lookup may involve looking in other packages whose external symbols
are inherited by the current package (see below). If the name is found,
the corresponding symbol is returned. If the name is not found, a new
symbol is created for it and is placed in the current package as an
internal symbol; if the name is seen again while this same package is
current, the same symbol will then be returned.
When a new symbol is created, a pointer to the package in which it is
initially placed is stored in the @i[package cell] of that symbol; the
package is said to be the symbol's @i[home package], and is said to
@i[own] the symbol. (Some symbols are not owned by any package; they
are said to be @i[uninterned], and their package cell contains NIL.)
Often it is desirable to refer to an external symbol in some package
other than the current one. This is done through the use of a
@i[qualified name], consisting of a package name, then a colon, then the
print name of the symbol. This causes the symbol's name to be looked up
in the specified package, rather than in the current one. For example,
``@b[editor:buffer]'' refers to the external symbol named ``@b[buffer]''
available in the package named ``@b[editor]'', regardless of whether
there is a symbol named ``@b[buffer]'' in the current package. If there
is no package named ``@b[editor]'', or if no symbol named ``@b[buffer]''
is available in ``@b[editor]'' or if ``@b[buffer]'' is an internal
symbol in ``@b[editor]'', a correctable error is signalled to ask the
user what he really wants to do.
On rare occasions, a user may need to refer to an @b[internal] symbol of
some package other than the current one. It is illegal to do this with
the colon qualifier, since accessing an internal symbol of some other
package is usually a mistake. However, this operation is legal if you
use ``@b[#:]'' as the separator in place of the usual colon. If
``@b[editor#:buffer]'' is seen, the effect is exactly the same as
reading ``@b[buffer]'' with @b[*package*] temporarily rebound to the
package whose name is ``@b[editor]''. This special-purpose qualifier
should be used with caution.
The package named @b[keyword] contains all keyword symbols used by the
Lisp system itself and by user-written code. Such symbols must be
easily accessible from any package, and name conflicts are not an issue
since these symbols are used only to label arguments and never to carry
package-specific values or properties. Because keyword symbols are used
so frequently, Common Lisp provides a special reader syntax for them:
any symbol preceded by a colon but no package name (for example
``@b[:foo]'') is added to (or looked up in) the @b[keyword] package as
an @i[external] symbol. The @b[keyword] package is also treated
specially in that whenever a symbol is added to the @b[keyword] package,
the symbol is automatically declared to be a constant and is made to
have itself as its value. This is why every keyword evaluates to
itself. As a matter of style, keywords should always be accessed using
the leading-colon convention; you never want to import or inherit
keywords into any other package.
Each symbol contains a package slot that is used to record the home
package of the symbol, or NIL if the symbol is uninterned. This slot
may be accessed by @b[symbol-package] @ref[%%%]. When an interned
symbol is printed, if it is an external symbol in the keyword package
then it is printed with a preceding colon; otherwise, if it is available
(directly or by inheritance) in the current package, it is printed
without any qualification; otherwise, it is printed with the name of the
home package as the qualifier, using ``@b[:]'' as the separator if the
symbol is external and ``@b[#:]'' if not.
A symbol that is uninterned (has no home package) is printed preceded by
``@b[#:]''. It is possible, by the clever use of import and unintern,
to create a symbol that has no recorded home package, but that in fact is
interned in some package. The system does not check for this.
In summary, the following four cases are defined:
@Begin[describe]
@b[foo:bar] @\Look up "bar" among the external symbols available in the
package named "foo".
@b[foo#:bar] @\Look up "bar" among the external and internal symbols
available in the package named "foo".
@b[:bar] @\The symbol named "bar" is a self-evaluating keyword.
@b[#:bar] @\The symbol named "bar" is uninterned.
@End[describe]
All other uses of colons within names of symbols are not defined by
Common Lisp, but are reserved for implementation-dependent use; this
includes names that end in a colon, contain two or more colons, or
consist of just a colon.
@section [Exporting and Importing Symbols]
Symbols from one package may be made available in another package in
two ways.
First, any individual symbol may be added to a package by use
of the @b[import] function. The form @b[(import 'editor:buffer)] takes
the external symbol named @b[buffer] in the @b[editor] package (this
symbol was located when the form was read by the Lisp reader) and adds
it to the current package as an internal symbol. The imported symbol is
not automatically exported from the current package, but if it is
already present and external, that is not changed. After the call to
@i[import] it is possible to refer to @b[buffer] in the importing package
without any qualifier. The status of @b[buffer] in the package named
@b[editor] is unchanged, and @b[editor] remains the home package for
this symbol. Once imported, a symbol is @i[present] in the
importing package and can only be removed by calling @b[unintern].
If the symbol is already present in the importing package, @b[import]
has no effect. If a distinct symbol with the name @b[buffer] is
available in the importing package (directly or by inheritance) a
correctable error is signalled, as described in the next section.
If the user really wants to do a shadowing import without getting an
error, he should use the @b[shadowing-import] function. This inserts
the symbol into the specified package as an internal symbol, regardless
of whether another symbol of the same name will be shadowed by this
action. If the package already contains a different symbol of the same
name, this will be uninterned from that package. The new symbol is
added to the package's shadowing-symbols list. @b[Shadowing-import]
should be used with caution. It changes the state of the package system
in such a way that the consistency rules do not hold across the change.
The second mechanism is provided by the @b[use-package] function. This
causes a package to inherit all of the external symbols of some other
package. These symbols become available as @i[internal] symbols of the
using package. That is, they can be referred to without a qualifier
while this package is current, but they are not passed along to any
other package that uses this package. Use-package checks carefully for
name conflicts between the newly imported symbols and those already
available in the importing package. This is described in detail in the
next section.
Often a user, working by default in the @b[user] package, will
load a number of packages into his Lisp to provide an augmented working
environment; then he will call @b[use-package] on each of these packages
so that he can easily access their external symbols.
@b[Unuse-package] undoes the effects of a previous @b[use-package]. The
external symbols of the used package are no longer inherited. However,
any symbols that have been imported into the using package continue to
be present in that package.
There is no way to inherit the @i[internal] symbols of another package;
to refer to an internal symbol, you must either make that symbol's home
package current, use a qualifier, or import that symbol into the current
package.
When @b[intern] or some other function wants to look up a symbol in a
given package, it first looks for the symbol among the external and
internal symbols of the package itself; then it looks through the
external symbols of the used packages in some unspecified order. The
order does not matter; according to the rules for handling name
conflicts (see below), if conflicting symbols appear in two or more
packages inherited by package X, a symbol of this name must also appear
in X itself as a shadowing symbol. Of course, implementations are free
to choose other, more efficient ways of implementing this search, as
long as the user-visible behavior is equivalent to what is described
here.
The @b[export] function takes a symbol that is available in some package
and makes it an external symbol of that package. If the symbol is
already available as an external symbol in the package, @b[export] has
no effect. If the symbol is directly present in the package as an
internal symbol, it is simply changed to external status. If it is
available as an internal symbol via @b[use-package], the symbol is first
imported into the package, then exported. (It is now present in this
package whether or not it continues to use the symbol's original
package.) If the symbol is not available at all in the specified
package, a correctable error is signalled which, upon continuing, asks
the user whether the symbol should be imported.
The @b[unexport] function is provided mainly as a way to undo erroneous
calls to @b[export]. It works only on symbols that are directly present
in the current package, switching them back to internal status. If
@b[unexport] is given a symbol that is already available as an internal
symbol in the current package, it does nothing; if it is given a symbol
that is not available in the package at all, it signals an error.
@section[Name Conflicts]
A fundamental invariant of the package system is that within one package
any particular name can only refer to one symbol. A @i[name conflict]
is said to occur when there is more than one candidate symbol and it is
not obvious which one to choose. If the system does not always choose
the same way, the read-read consistency rule would be violated. For
example, some programs or data might have been read in under a certain
mapping of the name to a symbol. If the mapping changes to a different
symbol, then additional programs or data are read, the two programs will
not access the same symbol even though they use the same name. Even if
the system did always choose the same way, a name conflict is likely to
result in a different mapping from names to symbols than was expected by
the user, causing programs to execute incorrectly. Therefore, any time
a name conflict occurs, an error is signalled. The user may continue
from the error and tell the package system how to resolve the conflict.
Note that if the same symbol is accessible to a package through more than
one path, for instance as an external of more than one package, or both
through inheritance and through direct presence in the package, there is
no name conflict. Name conflicts only occur between distinct symbols with
the same name.
The creator of a package can tell the system in advance how to resolve a
name conflict through the use of @i[shadowing]. Every package has a
list of shadowing symbols. A shadowing symbol takes precedence over any
other symbol of the same name that would otherwise be accessible to the
package. A name conflict involving a shadowing symbol is always
resolved in favor of the shadowing symbol, without signalling an error
(except for one exception involving @b[import] described below). The
functions @b[shadow] and @b[shadowing-import] may be used to declare
shadowing symbols.
Name conflicts are detected when they become possible, i.e. when the
package structure is altered. There is no need to check for name
conflicts during every name lookup.
The functions @b[use-package], @b[import], and @b[export] check for name
conflicts. @b[use-package] makes the external symbols of the package
being used accessible to the using package; each of these symbols is
checked for name conflicts with the symbols already accessible.
@b[import] adds a single symbol to the internals of a package, checking
for a name conflict with an existing symbol either present in the
package or accessible to it. @b[import] signals an error even if there
is a name conflict with a shadowing symbol, because two explicit
directives from the user are inconsistent. @b[export] makes a single
symbol accessible to all the packages that use the package from which
the symbol is exported. All of these packages are checked for
name conflicts: @b[(export @i[s] @i[p])] does
@b[(find-symbol (symbol-name @i[s]) @i[q])] for each package @i[q]
in @b[(package-used-by-list @i[p])]. Note that in the usual case of
an @b[export] during the initial definition of a package, the
@b[package-used-by-list] will be @b[nil] and the name conflict checking
will take no time.
@b[intern] does not need to do any name-conflict checking, because it
never creates a new symbol if there is already an accessible symbol with
the name given.
@b[shadow] and @b[shadowing-import] never signal a name-conflict error,
because by calling these functions the user has specified how any
possible conflict is to be resolved. @b[shadow] does name-conflict
checking to the extent that it checks whether a distinct existing symbol with
the specified name is accessible, and if so whether it is directly
present in the package or inherited; in the latter case a new symbol
is created to shadow it. @b[shadowing-import] does name-conflict
checking to the extent that it checks whether a distinct existing
symbol with the same name is accessible; if so it is shadowed by
the new symbol, which implies that it must be @b[unintern]ed if it was
directly present in the package.
@b[unuse-package], @b[unexport], and @b[unintern] (when the symbol being
@b[unintern]ed is not a shadowing symbol) do not need to do any
name-conflict checking, because they only remove symbols from a package;
they do not make any new symbols accessible.
@b[unintern] of a shadowing symbol can uncover a name conflict that had
previously been resolved by the shadowing. If package A uses packages
B and C, A contains a shadowing symbol @b[x], and B and C each contain external
symbols named @b[x], then @b[unintern]ing @b[x] from A will reveal a name
conflict between @b[b:x] and @b[c:x] if those two symbols are distinct.
In this case @b[unintern] will signal an error.
Aborting from a name-conflict error leaves the original symbol accessible.
Package functions always signal name-conflict errors before making any
change to the package structure. Note: when multiple changes are to be
made, for example when @b[export] is given a list of symbols, it is legal
for each change to be processed separately, so that aborting from a name
conflict caused by the second symbol in the list will not unexport the
first symbol in the list. However, aborting from a name conflict error
caused by @b[export] of a single symbol will not leave that symbol accessible
to some packages and inaccessible to others; @b[export]
appears as an atomic operation.
Continuing from a name-conflict error should offer the user a chance to
resolve the name conflict in favor of either of the candidates. The
package structure should be altered to reflect the resolution of the
name conflict, via @b[shadowing-import], @b[unintern], or @b[unexport].
A name conflict in @b[use-package] between a symbol directly present in the
using package and an external symbol of the used package may be resolved
in favor of the first symbol by making it a shadowing symbol, or in favor
of the second symbol by @b[unintern]ing the first symbol from the using
package. The latter resolution is dangerous if the symbol to be
@b[unintern]ed is an external symbol of the using package since it
will cease to be an external symbol.
A name conflict in @b[use-package] between two external symbols inherited
by the using package from other packages may be resolved in favor of
either symbol by importing it into the using package and making it a
shadowing symbol.
A name conflict in @b[export] between the symbol being exported and a
symbol already present in a package that would inherit the
newly-exported symbol may be resolved in favor of the exported symbol
by @b[unintern]ing the other one, or in favor of the already-present
symbol by making it a shadowing symbol.
A name conflict in @b[export] or @b[unintern] due to a package
inheriting two distinct symbols with the same name from two other
packages may be resolved in favor of either symbol by importing it into
the using package and making it a shadowing symbol, just as with
@b[use-package].
A name conflict in @b[import] between the symbol being imported and a
symbol inherited from some other package may be resolved in favor of the
symbol being imported by making it a shadowing symbol, or in favor
of the symbol already accessible by not doing the @b[import]. A
name conflict in @b[import] with a symbol already present in the
package may be resolved by @b[unintern]ing that symbol, or by not
doing the @b[import].
Good user-interface style dictates that @b[use-package] and @b[export],
which can cause many name conflicts simultaneously, first check for
all of the name conflicts before presenting any of them to the user.
The user may then choose to resolve all of them wholesale, or to resolve
each of them individually, requiring a lot of interaction but permitting
different conflicts to be resolved different ways.
Some implementations will have other ways of resolving name conflicts to
offer. For instance, if the symbols that conflict are not being used as
objects, but only as names for functions, it may be possible to "merge"
the two symbols by putting the function definition onto both symbols.
References to either symbol for purposes of calling a function would be
equivalent. A similar merging operation can be done for variable values
and for things stored on the property list. On the Lisp machine one can
also @i[forward] the value, function, and property cells so that future
changes to either symbol will propagate to the other one. Some other
implementations are able to do this with value cells, but not with
property lists. Only the user can know whether this way of resolving
a name conflict is adequate, i.e. the fact that there are two non-@b[eq]
symbols with the same name doesn't affect the correct operation of
his program. The value of offering symbol-merging as a way of resolving
name conflicts is that it can avoid the need to throw away the whole
Lisp world and start over, after correcting the package-definition forms
that caused the error.
@Section[Built-in Packages]
The following packages are built into the Common Lisp system:
@begin[description]
@b[lisp]@\The package named @b[lisp] contains the primitives of the
Common Lisp system. Its external symbols include all of the
user-visible functions and global variables that are present in the
Common Lisp system, such as @b[car], @b[cdr], @b[*package*], etc.
Almost all other packages will want to use @b[lisp] so that these
symbols are available without qualification.
@b[user]@\The @b[user] package is, by default, the current package at the time
a Common Lisp system starts up. This package uses the @b[lisp] package.
@b[keyword]@\This package contains all of the keywords used by built-in
or user-defined Lisp functions. Symbols that start with a colon are
treated as external symbols in the this package. All symbols in this
package are treated as constants that evaluate to themselves, so the
user can type @b[:foo] instead of @b[':foo].
@b[system]@\This package name is reserved to the implementation.
Normally this is used to contain names of implementation-dependent
system-interface functions. This package uses @b[lisp] and has the
nickname @b[sys].
@end[description]
@Section[Package System Functions and Variables]
Some of the following have been described earlier, but are included here
for completeness.
It is up to each implementation's compiler to ensure that when a
compiled file is loaded, all of the symbols in the file end up in the
same packages that they would occupy if the Lisp source file were
loaded. In most compilers, this will be accomplished by treating
certain package operations as though they are surrounded by
@b[(eval-when (compile load) ...). These operations are
@b[make-package], @b[in-package], @b[import], @b[export], @b[unexport],
@b[shadow], @b[shadowing-import], @b[use-package], and
@b[unuse-package]. To guarantee proper compilation in all Common Lisp
implementations, these functions should appear only at top-level within
a file. As a matter of style, it is suggested that each file contain
only one package, and that all of the package setup forms appear near
the start of the file.
@begin [implementation-note]
In the past, some Lisp compilers have read the entire file into Lisp
before processing any of the forms. Other compilers have arranged for
the loader to do all of its interns before evaluating any of the
top-level forms. Neither of these techniques will work in a
straightforward way in Common Lisp because of the presence of multiple
packages.
@end [implementation-note]
For the functions described here, all optional arguments named
@i[package] default to the current value of @b[*package*]. Where a
function takes an argument that is either a symbol or a list of symbols,
an argument of NIL is treated as an empty list of symbols.
@Defvar[Var {*package*}]
The value of this variable must be a package; this package is said to be
the current package. The initial value of @b[*package*] is the @b[user]
package.
The @b[load] function rebinds @b[*package*] to its current value. If
some form in the file changes the value of @b[*package*] during loading,
the old value will be restored when the loading is completed.
@Enddefvar
@Defun[Fun {make-package}, Args {@i[package-name] @key @i[nicknames]
@i[use]}]
Creates and returns a new package with the specified package name. The
@b[:nicknames] argument must be a list of strings to be used as
alternative names for the function. These names must not conflict with
any existing package names; if they do, a correctable error is
signalled.
The @b[:use] argument is a list of packages or package names whose
external symbols are to be inherited by the new package. These package
must already exist. If not supplied, @i[:use] defaults to a list of one
package, the @b[lisp] package.
@Enddefun
@Defun[Fun {in-package}, Args {@i[package-name] @key @i[nicknames] @i[use]}]
The @b[in-package] function is intended to be placed at the start of a
file containing a subsystem that is to be loaded into some package other
than @b[user]. If there is not already a package named @i[package-name], this
function is similar to @b[make-package], except that after the
new package is created, @b[*package*] is set to it. This binding will
remain in force until changed by the user (perhaps with another
@b[in-package] call), or until the @b[*package*] variable reverts to its
old value at the completion of a @b[load] operation.
If there is an existing package whose name is @i[package-name], the
assumption is that the user is re-loading a file after making some
changes. The existing package is augmented to reflect any new nicknames
or new packages in the @b[:use] list (with the usual error-checking) and
@b[*package*] is then set to this package.
@enddefun
@Defun[Fun {find-package}, Args {@i[name]}]
The @i[name] must be a string that is the name or nickname for a
package. Returns the corresponding package, or NIL if no such package
exists. This match ignores case (as in @b[string-equal]).
@Enddefun
@Defun[Fun {package-name}, Args {@i[package]}]
The argument must be a package. This function returns the string that
names that package.
@Enddefun
@Defun[Fun {package-nicknames}, Args {@i[package]}]
The argument must be a package. This function returns the list of
nickname strings for that package, not including the primary name.
@Enddefun
@Defun[Fun {package-use-list}, Args {@i[package]}]
Returns the list of other packages used by the argument package.
@Enddefun
@Defun[Fun {package-used-by-list}, Args {@i[package]}]
Returns the list of other packages that use the argument package.
@Enddefun
@Defun[Fun {package-shadowing-symbols}, Args {@i[package]}]
Returns the list of symbols in that have been declared as shadowing
symbols in this package by @b[shadow] or @b[shadowing-import]. All
symbols on this list are present in the specified package.
@Enddefun
@Defun[Fun {list-all-packages}, Args {}]
This function returns a list of all packages that currently exist in the
Lisp system.
@Enddefun
@Defun[Fun {intern}, Args {@i[string] @optional @i[package]}]
@i[Package], which defaults to the current package, is
searched for a symbol with the name specified by the @b[string]
argument. This search will include inherited symbols, as described
above. If a symbol with the specified name is found, it is returned.
If no such symbol is found, one is created and is installed in the
current package as an internal symbol. This symbol is returned.
@Incompatibility{Conceptually, @b[intern] translates a
string to a symbol. In Maclisp and several other Lisps, @b[intern] can
take either a string or a symbol as its argument; in the latter case,
the symbol's print name is extracted and used as the string. However,
this leads to some confusing issues about what to do if
@b[intern] finds a symbol that is not @b[eq] to the argument symbol. To
avoid such confusion, we require the argument to be a string.}
@Enddefun
@Defun[Fun {find-symbol}, Args {@i[string] @optional @i[package]}]
This is identical to @b[intern], but it never creates a new symbol. If
a symbol with the specified name is found in the current package,
directly or by inheritance, the symbol found is returned. The second
return value is T, indicating that the symbol was found. The third
value is T if the symbol is an external symbol in the specified package,
NIL if it is internal. If the symbol is not found in the specified package,
@b[find-symbol] returns NIL for all three values.
@Enddefun
@Defun[Fun {find-external-symbol}, Args {@i[string] @optional @i[package]}]
This is identical to @b[find-symbol], but it does not look for internal
symbols even in @i[package] itself. This is the type of search done by
the reader for symbols qualified with a package name and a colon. The
return values are the same as for @b[find-symbol], with the third return
value always being T (external symbol) if a symbol is found.
@Enddefun
@Defun[Fun {unintern}, Args {@i[symbol] @optional @i[package]}]
If the specified symbol is present in the specified package, it is
removed from this package, and also from the package's shadowing-symbols
list if it is present there. Moreover, if @i[package] is the home
package for the symbol, the symbol is made to have no home package.
@b[Unintern] returns T if it actually removed a symbol, and NIL otherwise.
@b[Unintern] should be used with caution. It changes the state of the
package system in such a way that the consistency rules do not hold
across the change.
@Incompatibility{The equivalent of this in @maclisp is @f[remob].}
@Enddefun
@Defun[Fun {export}, Args {@i[symbols] @optional @i[package]}]
The @i[symbols] argument should be a list of symbols, or possibly a single
symbol. These symbols become available as external symbols in the
current package. (See the sections above for details.) Returns T.
By convention, a call to @f[export] listing all exported symbols is
placed near the start of a file to advertise which of the symbols
mentioned the file are intended to be used by other programs.
@Enddefun
@Defun[Fun {unexport}, Args {@i[symbols] @optional @i[package]}]
The argument should be a list of symbols, or possibly a single symbol.
These symbols become internal symbols in @i[package]. (See the sections above for details.) Returns T.
@Enddefun
@Defun[Fun {import}, Args {@i[symbols] @optional @i[package]}]
The argument should be a list of symbols, or possibly a single symbol.
These symbols become internal symbols in @i[package], and can therefore
be referred to without a colon qualifier. @b[Import] signals a
correctable error if any of the imported symbols has the same name as
some distinct symbol already available in the package. (See the
sections above for details.) Returns T.
@Enddefun
@Defun[Fun {shadowing-import}, Args {@i[symbols] @optional @i[package]}]
This is like import, but it does not signal an error even if the
importation of a symbol would shadow some symbol already available in
the package. In addition to being imported, the symbol is placed on the
shadowing-symbols list of @i[package]. (See the sections above for
details.) @b[Shadowing-import] should be used with
caution. It changes the state of the package system in such a way that
the consistency rules do not hold across the change. Returns T.
@Enddefun
@Defun[Fun {shadow}, Args {@i[symbols] @optional @i[package]}]
The argument should be a list of symbols, or possibly a single symbol.
The print-name of each symbol is extracted, and the current package is
searched for a symbol of that name. If such a symbol is present in this
package (directly, not by inheritance) then nothing is done. Otherwise,
a new symbol is created with this print name, and it is inserted in the
current package as an internal symbol. The symbol is also placed on the
shadowing-symbols list of @i[package]. (See the sections above for
details.) @b[Shadow] should be used with
caution. It changes the state of the package system in such a way that
the consistency rules do not hold across the change. Returns T.
@Enddefun
@Defun[Fun {use-package}, Args {@i[packages-to-use] @optional @i[package]}]
The @i[packages-to-use] argument should be a list of packages or package
names, or possibly a single package or package name. These packages are
added to the use-list of @i[package] if they are not there already. All
external symbols in the packages to use become available in @i[package]
as internal symbols. (See the sections above for details.) Returns
T.
@enddefun
@Defun[Fun {unuse-package}, Args {@i[packages-to-unuse]}]
The @i[packages-to-unuse] argument should be a list of packages or
package names, or possibly a single package or package name. These
packages are removed from the use-list of @i[package]. Returns T.
@enddefun
@Defun[Fun {find-all-symbols}, Args {@i[string-or-symbol]}]
Searches every package in the Lisp system for symbols whose print-name is the
specified string, and returns a list of such symbols. This search is
case-sensitive. If the argument is a symbol, its print-name supplies
the string to be searched for.
@enddefun
@Defmac[Fun {do-symbols}, Args {(@i[var] @Mopt<@i[package]> @Mopt<@i[result-form]>) @Mstar<@i[declaration]> @mstar<@i[tag] @mor @i[statement]>}]
@b[Do-symbols] provides straightforward iteration over the symbols of a
package. The body is performed once for each symbol available in the
@i[package], in no particular order, with the variable @i[var] bound to
the symbol. Then @i[resultform] (a single form, @i[not] an implicit
@b[progn]) is evaluated, and the result is the value of the
@b[do-symbols] form. (When the @i[resultform] is evaluated, the control
variable @i[var] is still bound, and has the value @nil.) If
@i[resultform] is omitted, the result is NIL. @b[Return] may be used to
terminate the iteration prematurely. If execution of the body affects
which symbols are contained in the @i[package], other than possibly to
remove the symbol currently the value of @i[var] by using @b[unintern],
the effects are unpredictable.
@Enddefmac
@Defmac[Fun {do-external-symbols}, Args {(@i[var] @Mopt<@i[package]> @Mopt<@i[result-form]>) @Mstar<@i[declaration]> @mstar<@i[tag] @mor @i[statement]>}]
@b[Do-external-symbols] is just like @b[do-symbols], except that only
the external symbols of the specified package are scanned.
@Enddefmac
@Defmac[Fun {do-all-symbols}, Args {(@i[var] @Mopt<@i[result-form]>) @Mstar<@i[declaration]> @mstar<@i[tag] @mor @i[statement]>}]
This is similar to @b[do-symbols], but executes the body once for every
symbol contained in every package. (This may not get all symbols
whatsoever, depending on the implementation.) It is @i[not] in general
the case that each symbol is processed only once, since a symbol may
appear in many packages.
@Enddefmac
@Section[Modules]
A @i[module] is a Common Lisp subsystem that is loaded from one or more
files. A module is normally loaded as a single unit, regardless of how
many files are involved. A module may consist of one package or several
packages. The file-loading process is necessarily
implementation-dependent, but Common Lisp provides some very simple
portable machinery for naming modules, keeping track of which modules
have been loaded, and for loading modules as a unit.
@Defvar[Var {*modules*}]
@Defun[Fun {provide}, Args {@i[module-name]}]
@Defun1[Fun {require}, Args {@i[module-name] @optional @i[pathname]}]
Each module has a unique name (a string). If the module consists of a
single package, it is customary for the package and module names to be
the same. The variable @b[*modules*] is a list of names of the modules
that have been loaded into the Lisp system so far. The @b[provide]
function adds a new module name to this list, thereby indicating that
the module in question has been loaded.
The @b[require] function tests whether a module is already present
(using a case-insensitive comparison) and, if not, loads the appropriate
file or set of files. The pathname argument, if present, is a single
pathname or a list of pathenames whose files are to be loaded in order,
left to right. If the pathname argument is NIL or is not provided, the
system will attempt to determine which files to load in some
system-dependent manner. This will typically involve some central
registry of module names and the associated file-lists.
@section [An Example]
Most users will want to load and use packages but will never need to
build one. Often, a user will load a number of packages into the
@b[user] package whenever he uses Common Lisp. Most implementations
will provide some sort of "init file" mechanism to make such setup
automatic when the Lisp starts up.
@begin [Lisp]
;;; Lisp init file for I. Newton.
;;; Set up the USER package the way I like it.
;;; Calculus is used a lot. Get easy access to all its symbols.
(require "calculus")
(use-package "calculus")
;;; Same for Newtonian mechanics.
(require "newtonian-mechanics")
(use-package "newtonian-mechanics")
;;; I just want a few thing from here, and other things conflict.
;;; Import just what I need into the USER package.
(require "relativity")
(import '(relativity:speed-of-light
relativity:ignore-small-errors))
;;; These are worth loading, but I will use qualifiers to get at any
;;; symbols I need.
(require "phlogiston")
(require "alchemy")
@end [Lisp]
When each of two files uses some symbols from the other, we must be
careful to put the contents of the file in the file in the proper order.
Typically each file contains a single package that is a complete module.
The contents of such a file should include the following items, in
order:
@Begin[enumerate]
A @b[provide] call that announces the module name.
An @b[in-package] call that establishes the package.
A @b[shadow] call that establishes any local symbols that will shadow
symbols that would otherwise be inherited from packages that this
package will use.
An @b[export] call that establishes all of this package's external
symbols.
Any number of @b[require] calls to load other modules which the
contents of this file might want to use or refer to. By placing these
@b[requires] calls here, we make it possible for the packages being
loaded to refer to external symbols in this package.
Any number of @b[use-package] and @b[import] calls, to make it the
symbols from other packages available in this package.
Finally, the definitions making up the contents of this package/module.
@End[enumerate]
Now, suppose that the @b[phlogiston] and @b[alchemy] packages are
single-file, single-package modules as described above. Phlogiston
wants to use the alchemy package, and alchemy wants to use several
external symbols from phlogiston. The following definitions allow the
user to supply @b[require] statement for either of these modules, or for
both of them in either order.
The file "alchemy.lisp":
@begin [lisp]
;;; Alchemy functions, written and maintained by Merlin, Inc.
;;; Both the module and the package are named "alchemy".
(provide "alchemy")
(in-package "alchemy")
;;; Nothing to shadow.
;;; Here is our external interface.
(export '(lead-to-gold gold-to-lead antimony-to-zinc elixir-of-life))
;;; This file uses some functions from the phlogiston package/module.
(require "phlogiston")
;;; We use this a lot, so import it. It's external in phlogiston package.
(import '(phlogiston:make-fire-bottle))
;;; Now for the real contents of this file.
(defun lead-to-gold (x)
"Takes a quantity of lead, returns gold."
(when (> (phlogiston:heat-flow x) 3) ; Using a qualified symbol.
(make-fire-bottle x)) ; Using an imported symbol.
(gild x))
;;; And so on ...
@end [lisp]
The file "phlogiston.lisp":
@begin [lisp]
;;; Phlogiston functions, written and maintained by Thermofluidics, Ltd.
;;; Both the module and the package are named "phlogiston".
(provide "phlogiston")
(in-package "phlogiston")
;;; Nothing to shadow.
;;; Here is our external interface.
(export '(heat-flow cold-flow mix-fluids separate-fluids
burn make-fire-bottle))
;;; This file uses some functions from the alchemy package/module.
(require "alchemy")
;;; We use alchemy functions a lot, so use the package.
(use-package "alchemy")
;;; The real contents of this package/module.
(defun heat-flow (amount x y)
"Make some amount of heat flow from x to y."
(when feeling-weak
(quaff (elixir-of-life))) ; No qualifier needed.
(push-heat amount x y))
;;; And so on ...
@end [lisp]
For very large packages whose contents are spread over several files
(the @b[lisp] package is an example), it is recommended that the author
create the package and declare all of the shadows and external symbols
in a separate file, so that this can be loaded before anything which
might use symbols from this package.
∂18-May-83 2313 Moon@SCRC-TENEX error proposal not so hard to implement
Received: from SU-DSN by SU-AI with PUP; 18-May-83 23:13 PDT
Received: From MIT-XX by SU-DSN.ARPA; Wed May 18 23:15:14 1983
Received: from SCRC-EUPHRATES by SCRC-SPANIEL with CHAOS; Thu 19-May-83 02:14:51-EDT
Date: Thursday, 19 May 1983, 02:14-EDT
From: David A. Moon <Moon at SCRC-TENEX>
Subject: error proposal not so hard to implement
To: Common-Lisp at su-ai
I implemented everything in my error proposal this evening, including
hairy interface to the debugger. It took about five hours.
∂19-May-83 1457 @MIT-MC:KMP@MIT-MC Comments on wording in "Revenge of the Packages"
Received: from MIT-MC by SU-AI with TCP/SMTP; 19 May 83 14:57:29 PDT
Date: Thursday, 19 May 1983, 18:00-EDT
From: Kent M. Pitman <KMP at MIT-MC>
Subject: Comments on wording in "Revenge of the Packages"
To: Fahlman at CMUC
Cc: Common-Lisp at SAIL
These comments refer only to wording that I think should be cleared up;
not to semantic problems in the spec.
I think that
A symbol that is uninterned (has no home package) is printed preceded by
``@b[#:]''. It is possible, by the clever use of import and unintern,
to create a symbol that has no recorded home package, but that in fact is
interned in some package. The system does not check for this.
would be far less confusing as
If the symbol's home package is NIL, it will be printed preceded by
``@b[#:]''. Uninterned symbols, such as those created by GENSYM,
are the most common example. It may be possible through `clever'
combinations of @b[import] and @b[unintern] to create a symbol
which has no recorded home package, but which is in fact interned in
some package; for efficiency reasons, this pathological case is not checked
for, and such symbols will also be printed preceded by ``@b[#:]''.
I think we should try to avoid statements which if read out of context will
have strong implications that are not strictly true.
Also, your descriptions of the syntaxes should take one of two moods, but not
be split. Either you should describe why a symbol prints a certain way, or you
should describe what the reader does when it encounters a certain symbol, or
both separately, but not both mixed together as you do in:
@b[foo:bar] @\Look up "bar" among the external symbols available in the
package named "foo".
@b[foo#:bar] @\Look up "bar" among the external and internal symbols
available in the package named "foo".
@b[:bar] @\The symbol named "bar" is a self-evaluating keyword.
@b[#:bar] @\The symbol named "bar" is uninterned.
I would suggest either describing the meaning of a symbol printing a certain way,
as in:
@b[foo:bar] @\The symbol "bar" is among the external symbols available in
the package named "foo".
@b[foo#:bar] @\The symbol "bar" has a home package of "foo", but is not
an exported symbol of that package.
@b[:bar] @\The symbol named "bar" is on the keyword package.
@b[#:bar] @\The symbol named "bar" has no home package information.
or the meaning to the reader of the given syntaxes, as in:
@b[foo:bar] @\Expect to find an external symbol named "bar" in the "foo"
package and use that.
@b[foo#:bar] @\If there is a symbol "bar" on the "foo" package, whether
external or not, use that. If there is no such symbol, create one and use it.
@b[:bar] @\If there is an external symbol on the keyword package named
"bar", use it. Otherwise, create such a symbol (binding it to itself),
and use that.
@b[#:bar] @\Create a symbol named "bar" but do not intern it on any package.
or some such.
--kmp
∂22-May-83 1507 FAHLMAN@CMU-CS-C Last call for nits
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 22 May 83 15:07:34 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 22 May 83 18:08:15 EDT
Date: Sun, 22 May 1983 18:08 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: common-lisp@su-ai
Subject: Last call for nits
I have changed the language of the package proposal slightly to
incorporate most of KMP's suggestions on wording. None of this changes
anything substantive in the proposal. I will spare the ARPANET mail
servers another moby transmission of the whole thing -- if anyone wants
to look at the changes, they're on CMUC as <fahlman.slisp>package.mss.
The latest proposal has been out almost a week and nobody has complained
about anything substantive. If I hear no objections within the next 24
hours, I will turn this over to Guy for inclusion in the manual (once he
has converted it to a stylistically consistent form) and we can chalk up
one more small victory for Federalism.
Though I was a bit overwhelmed by the volume of criticism that came in,
I think that the discussion was a healthy one and that the result is a
much better package system than we would have had without this process.
Thanks to all who participated.
-- Scott
∂23-May-83 1623 David.Dill@CMU-CS-A EXPORT after USE-PACKAGE
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 23 May 83 16:23:13 PDT
Date: 23 May 1983 1922-EDT (Monday)
From: David.Dill@CMU-CS-A (L170DD60)
To: common-lisp@su-ai
Subject: EXPORT after USE-PACKAGE
Message-Id: <23May83.192214.DD60@CMU-CS-A>
It seems to me that the issue that has caused the most grief, directly
or indirectly, in the design of the package system has been what to
do when a package decides to change its export list after it has been
used by another package. I have been operating under the assumption
that the only legitimate reason to do this is during debugging or
development, to recover from a mistake in setting up a package or
to "remove the back" from a package in order to poke around inside
conveniently. Does everyone else believe this (Moon in particular)?
If this is the case, then saying so in the manual could simplify some
of the explanations of lookup rules, and also allow more flexibility
in individual implementations (e.g. copy vs. search rules).
∂23-May-83 1639 BENSON@SPA-NIMBUS Return of the Packages Strikes Back
Received: from SU-DSN by SU-AI with PUP; 23-May-83 16:39 PDT
Received: From MIT-XX by SU-DSN.ARPA; Mon May 23 16:40:39 1983
Date: Monday, 23 May 1983, 16:39-PDT
From: BENSON at SPA-NIMBUS
Subject: Return of the Packages Strikes Back
To: Fahlman at CmuC
Cc: Common-Lisp at SU-AI
The latest package.mss looks great. I hate to be late with this, but there is
one very minor clarification that should go in. In the section "Package Names"
there is a sentence that reads:
Package name strings retain whatever mixture of upper and lower case characters
the user supplies, but the translation from names to packages is case-
insensitive, so users can generally refer to packages without worrying about
case.
The meaning of "retain" in this context is not entirely clear. Clearly it must
refer to the string returned by PACKAGE-NAME; that's the only way to get a
string back from a package. That should be stated explicitly. Instead, I
suggest leaving out any mention of retention of case, since the same issues
apply here as in the case of symbols. Is the case retained that of the string
given when the package was created, or that of the last call to FIND-PACKAGE?
How does this affect printing? If anything, it should be stated that the string
returned by PACKAGE-NAME is always upper case, to match the treatment of symbols
by READ. Of course, FIND-PACKAGE is really analogous to INTERN, which is
sensitive to case...
As long as we're on the subject, the printing process for package prefixes
should be described, probably in the Input and Output chapter. I guess what's
expected is that package prefixes get printed "like" symbols, w.r.t. slashifying
special characters and the effect of *PRINCASE*, except perhaps it's impossible
to "really" have a lower case character in a package name like in a symbol.
Just when you thought it was safe to go back in the water...
∂23-May-83 1713 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN Alphabetic case in package names
Received: from MIT-MC by SU-AI with TCP/SMTP; 23 May 83 17:12:39 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Mon 23-May-83 20:11:36-EDT
Date: Monday, 23 May 1983, 20:08-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Alphabetic case in package names
To: BENSON%SPA-NIMBUS%MIT-MC@SU-DSN
Cc: Common-Lisp@SU-AI
In-reply-to: The message of 23 May 83 19:39-EDT from BENSON at SPA-NIMBUS
Date: Monday, 23 May 1983, 16:39-PDT
From: BENSON at SPA-NIMBUS
...Instead, I
suggest leaving out any mention of retention of case, since the same issues
apply here as in the case of symbols.
Not so. Symbols are created implicitly, on first reference. Packages are
created explicitly, with MAKE-PACKAGE (or whatever it's called now). Except
this isn't completely true, since if you use IN-PACKAGE (or whatever it's called now)
you don't know whether you are creating a package or adding to an existing package.
Also, for historical reasons, and perhaps even good reasons, you are allowed
to have distinct symbols A and |a|. I see no good reason to allow anything of
the sort for packages.
Presumably the intention is that the casification of the "name" argument to MAKE-PACKAGE
and IN-PACKAGE is remembered the first time it is seen, and given back to you by
PACKAGE-NAME, by the printed representation of the package, when the package appears
as a prefix in a qualified name, and by whatever user-interface things talk about
packages (they get it from PACKAGE-NAME).
It may turn out that in practice it looks better for the casification of package
prefixes in qualified names to be controlled by *PRINCASE* rather than to reflect
the way it was originally written.
∂23-May-83 1714 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN EXPORT after USE-PACKAGE
Received: from MIT-MC by SU-AI with TCP/SMTP; 23 May 83 17:13:51 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Mon 23-May-83 20:16:57-EDT
Date: Monday, 23 May 1983, 20:14-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: EXPORT after USE-PACKAGE
To: common-lisp@su-ai
In-reply-to: <23May83.192214.DD60@CMU-CS-A>
Date: 23 May 1983 1922-EDT (Monday)
From: David.Dill@CMU-CS-A (L170DD60)
I have been operating under the assumption
that the only legitimate reason to do this is during debugging or
development, to recover from a mistake in setting up a package or
to "remove the back" from a package in order to poke around inside
conveniently. Does everyone else believe this (Moon in particular)?
Yes.
Also to alter a package that has already been created in a suspended
environment, when it would be too expensive to re-create the suspended
environment from the ground up. The terminal behind my back is connected
to a machine containing such an environment that was made more than
six months ago and would take a couple of weeks effort to reconstruct.
If this is the case, then saying so in the manual could simplify some
of the explanations of lookup rules, and also allow more flexibility
in individual implementations (e.g. copy vs. search rules).
But it's important that no matter how it is implemented, and no matter
whether it is fast or slow, it works. If the implementation has a separate
hash table for every package, and USE-PACKAGE makes entries in that hash
table, so that INTERN never does more than one hash lookup, then EXPORT
must make multiple hash insertions--one in every package on the
package-used-by list, except for those that shadow.
∂23-May-83 2047 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN Maphash
Received: from MIT-MC by SU-AI with TCP/SMTP; 23 May 83 20:46:59 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Mon 23-May-83 23:38:50-EDT
Date: Monday, 23 May 1983, 23:35-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Maphash
To: Scott E. Fahlman <Fahlman%CMU-CS-C@SU-DSN>
Cc: common-lisp@su-ai
In-reply-to: The message of 19 May 83 00:23-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: Thu, 19 May 1983 00:23 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
Since MAPHASH returns NIL, there is no elegant way to turn the
contents of a hashtable into a list. What would people think of
flushing MAPHASH and replacing it with DO-HASH ?
Is (defun hash-table-to-alist (ht)
(let ((alist nil))
(do-hash ((key value) ht)
(push (cons key value) alist))
alist))
more elegant than
(defun hash-table-to-alist (ht)
(let ((alist nil))
(maphash #'(lambda (key value)
(push (cons key value) alist))
ht)
alist))
?
You aren't allowed to base your decision on the fact that both your CL
implementation and my CL implementation are currently in violation of
the standard, such that the latter version doesn't work unless alist is
declared special. You also aren't allowed to base your decision on the
fact that the best way to do this operation is with LOOP.
∂23-May-83 2231 FAHLMAN@CMU-CS-C Maphash
Received: from SU-DSN by SU-AI with PUP; 23-May-83 22:31 PDT
Received: From CMU-CS-C by SU-DSN.ARPA; Mon May 23 22:33:18 1983
Received: ID <FAHLMAN@CMU-CS-C>; 24 May 83 01:31:20 EDT
Date: Tue, 24 May 1983 01:31 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: David A. Moon <Moon%SCRC-TENEX@MIT-MC>
Cc: common-lisp%su-ai@SU-DSN
Subject: Maphash
In-reply-to: Msg of 23 May 1983 23:35-EDT from David A. Moon <Moon%SCRC-TENEX at MIT-MC>
Well, if we assume an implementation in which the lexical-binding
problems have been solved (as we must in these discussions, I guess) I
must admit that both forms look about equally "elegant", since they are
nearly identical. I have three reasons for preferring the DO form:
1. A lingering feeling that MAP forms are flaky and are generally to be
avoided, probably left over from the days in which the binding issues
were not worked out. So this is not terribly rational, but it's still a
pretty strong aversion with me.
2. A lingering feeling that MAP forms are inherently less efficient,
since they require an extra function call. Of course, a sufficiently
wily compiler could eliminate this call, but I bet that the inefficiency
will be showing up in a lot of implementations for some time to come.
3. Perhaps strongest: the observation that we have gone to DO-SYMBOL,
etc., and that we should try to use the same style everywhere. (I hope
that this will not lead to the counter-proposal that we should go to
MAP-forms everywhere, but I probably hope in vain.)
I guess I'm not adamant about this, but for the reasons listed above I
would prefer the DO-HASH form.
-- Scott
∂23-May-83 2304 FAHLMAN@CMU-CS-C Return of the Packages Strikes Back
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 23 May 83 23:04:18 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 24 May 83 02:04:44 EDT
Date: Tue, 24 May 1983 02:04 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: BENSON%SPA-NIMBUS@mit-mc
Cc: Common-Lisp@SU-AI
Subject: Return of the Packages Strikes Back
In-reply-to: Msg of 23 May 1983 16:39-PDT from BENSON at SPA-NIMBUS
I tried to answer this earlier, but SPA-NIMBUS is not a real host, and
our local mailer cleverly puts such messages into the dumpster. What is
"SPA" anyway?
Moon is right: the package name description means what it says about
cases, and not what you imagine it is trying to say. I'll put in some
phrase about "unlike the way case is handled in symbols" to emphasize
this.
-- Scott
∂23-May-83 2347 Moon@SCRC-TENEX One last diddle to my error proposal
Received: from SU-DSN by SU-AI with PUP; 23-May-83 23:47 PDT
Received: From MIT-XX by SU-DSN.ARPA; Mon May 23 23:49:22 1983
Received: from SCRC-EUPHRATES by SCRC-SPANIEL with CHAOS; Tue 24-May-83 02:47:27-EDT
Date: Tuesday, 24 May 1983, 02:47-EDT
From: David A. Moon <Moon at SCRC-TENEX>
Subject: One last diddle to my error proposal
To: common-lisp at su-ai
I want to interchange the first two arguments to CERROR, so that the
description of what happens when you continue (or rather the FORMAT
string that builds that description) comes first, and then the rest
of the arguments are just like the arguments to ERROR. Any problems
with this?
∂24-May-83 0910 FAHLMAN@CMU-CS-C One last diddle to my error proposal
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 24 May 83 09:10:03 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 24 May 83 12:09:46 EDT
Date: Tue, 24 May 1983 12:09 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: David A. Moon <Moon%SCRC-TENEX@mit-mc>
Cc: common-lisp@su-ai
Subject: One last diddle to my error proposal
In-reply-to: Msg of 24 May 1983 02:47-EDT from David A. Moon <Moon at SCRC-TENEX>
I don't feel passionately about this switch, but to me it seems much more
intuitive to have the "error message" string come before the "and if you
proceed" string. They will presumably appear in the original order in
the error dialogue. I bet if we switch it, lots of users will get burned
the first few times they use it.
You don't say why you want to make the switch -- just so it looks more
like ERROR if you cover up the function name and the first arg?
-- Scott
∂24-May-83 1309 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN One last diddle to my error proposal
Received: from MIT-MC by SU-AI with TCP/SMTP; 24 May 83 13:08:50 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Tue 24-May-83 15:24:16-EDT
Date: Tuesday, 24 May 1983, 15:21-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: One last diddle to my error proposal
To: Scott E. Fahlman <Fahlman%CMU-CS-C@SU-DSN>
Cc: David A. Moon <Moon%SCRC-TENEX%mit-mc@SU-DSN>, common-lisp@su-ai
In-reply-to: The message of 24 May 83 12:09-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: Tue, 24 May 1983 12:09 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
I don't feel passionately about this switch,
[switch of the order of the first two arguments to CERROR]
but to me it seems much more
intuitive to have the "error message" string come before the "and if you
proceed" string. They will presumably appear in the original order in
the error dialogue. I bet if we switch it, lots of users will get burned
the first few times they use it.
This could be a problem, and indeed that's the reasoning I followed
originally that caused me to put the continue-message string first. On
the other hand, since it's called "C ERROR" the "C" part should come
before the "ERROR" part. We can't win.
You don't say why you want to make the switch -- just so it looks more
like ERROR if you cover up the function name and the first arg?
Exactly. Now, the reason why that is important will not appear until Common
Lisp has conditions. I'm not going to send out a proposal for conditions
until after the first edition of the manual is out, to avoid distraction
from more important things. But I'm thinking about it a little.
∂24-May-83 1315 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN One last diddle to my error proposal
Received: from MIT-MC by SU-AI with TCP/SMTP; 24 May 83 13:15:18 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Tue 24-May-83 15:24:16-EDT
Date: Tuesday, 24 May 1983, 15:21-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: One last diddle to my error proposal
To: Scott E. Fahlman <Fahlman%CMU-CS-C@SU-DSN>
Cc: David A. Moon <Moon%SCRC-TENEX%mit-mc@SU-DSN>, common-lisp@su-ai
In-reply-to: The message of 24 May 83 12:09-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: Tue, 24 May 1983 12:09 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
I don't feel passionately about this switch,
[switch of the order of the first two arguments to CERROR]
but to me it seems much more
intuitive to have the "error message" string come before the "and if you
proceed" string. They will presumably appear in the original order in
the error dialogue. I bet if we switch it, lots of users will get burned
the first few times they use it.
This could be a problem, and indeed that's the reasoning I followed
originally that caused me to put the continue-message string first. On
the other hand, since it's called "C ERROR" the "C" part should come
before the "ERROR" part. We can't win.
You don't say why you want to make the switch -- just so it looks more
like ERROR if you cover up the function name and the first arg?
Exactly. Now, the reason why that is important will not appear until Common
Lisp has conditions. I'm not going to send out a proposal for conditions
until after the first edition of the manual is out, to avoid distraction
from more important things. But I'm thinking about it a little.
∂24-May-83 1427 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN maphash and do-hash
Received: from MIT-MC by SU-AI with TCP/SMTP; 24 May 83 14:26:58 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Tue 24-May-83 16:30:15-EDT
Date: Tuesday, 24 May 1983, 16:28-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: maphash and do-hash
To: common-lisp@su-ai
In-reply-to: The message of 24 May 83 01:31-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Well, we can certainly implement either maphash or do-hash or both
with no problems. So we'll wait and see what's in the manual.
∂24-May-83 2035 FAHLMAN@CMU-CS-C EXPORT after USE
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 24 May 83 20:35:35 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 24 May 83 23:36:36 EDT
Date: Tue, 24 May 1983 23:36 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: David.Dill@λCMU-CS-A (L170DD60)λ
Cc: common-lisp@su-ai
Subject: EXPORT after USE
In-reply-to: Msg of 24 May 1983 1536-EDT () from David.Dill at CMU-CS-A (L170DD60)
Well, we could leave this unbound, or we could restrict EXPORT after USE
to signal an error, but the proposal as it now stands looks OK to me,
the problems with inheritance semantics seem to have been overcome, and
I would need a really compelling reason to change it now.
-- Scott
∂25-May-83 0730 David.Dill@CMU-CS-A EXPORT after USE
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 24 May 83 13:27:08 PDT
Date: 24 May 1983 1536-EDT (Tuesday)
From: David.Dill@CMU-CS-A (L170DD60)
To: common-lisp@su-ai
Subject: EXPORT after USE
Message-Id: <24May83.153655.DD60@CMU-CS-A>
Received: from CMU-CS-PT by CMU-CS-A; 24-May-83 12:23:13-EDT
It is really not clear to me why the effects of EXPORT after USE have to
be the same in all common lisp implementations. It is not hard to
imagine debugging tools that can track down and help resolve symbol
conflicts caused by this in various ways for various implementations.
The proposed scheme is not the only way to do this.
I'm not complaining about this because I want to implement a "copy"
system in Spice Lisp. It just seems to me that there is a natural
division between a common subset of the current proposal requiring
that all symbols be exported before the package is used, and the
wizard-level hacking necessary during development, which can be
implementation-dependent (it is clearly not going to be possible to
move code to another dialect of common lisp when it would take
two or three weeks to rebuild it from sources).
This seems to be consistent with the principles just applied to the
error system revisions.
-Dave
∂25-May-83 1033 David.Dill@CMU-CS-A EXPORT after USE
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 25 May 83 10:33:00 PDT
Date: 25 May 1983 1252-EDT (Wednesday)
From: David.Dill@CMU-CS-A (L170DD60)
To: common-lisp@su-ai
Subject: EXPORT after USE
Message-Id: <25May83.125226.DD60@CMU-CS-A>
Since we all believe that exporting from a used package is a debugging
operation, there should definitely be something in the package chapter
that makes this clear -- "finished" systems should not screw around
with export lists after a package has been used.
A second suggestion is that we leave the results of messing around with
the implementation internals of a common lisp dialect up to that dialect,
in this case by not specifying the exact behavior when export lists
are changed after a package has been used (although maybe the manual
should allude to the existence of mechanisms for dealing with this sort
of operation). This will allow room to experiment, in order to find the
best behavior when export lists are diddled, and to find more efficient
implementations of INTERN.
I fully support the notion that individual implementations should be
aware of the need for changing export lists for debugging and patching --
but it shouldn't be a part of common lisp.
Except for this issue, I'm happy with the current proposal.
-Dave
∂25-May-83 1304 @USC-ECL,@MIT-ML:BSG%SCRC-TENEX@MIT-ML REDUCE Change
Received: from USC-ECL by SU-AI with TCP/SMTP; 25 May 83 13:03:48 PDT
Received: from MIT-ML by USC-ECL; Wed 25 May 83 13:04:27-PDT
Received: from SCRC-BORZOI by SCRC-TENEX with CHAOS; Wed 25-May-83 13:31:22-EDT
Date: Wednesday, 25 May 1983, 13:29-EDT
From: Bernard S. Greenberg <BSG%SCRC-TENEX@MIT-ML>
Subject: REDUCE Change
To: common-lisp%su-ai@usc-ecl
Cc: common-lisp-implementors%SCRC-TENEX@MIT-ML
What is the reason for this new wart in the definition of REDUCE, i.e.,
REDUCE of a one-element subsequence does not invoke the function?
It is not at all consistent with the rest of the definition of the
function. The specific (reduce '(foo) #'+) example in the manual
seems to me counterintuitive. I guess my big complaint is that this
"feature" does not fall out of the code nicely at all, and the amount
of code spent worrying about it, given indefinite list ends, :from-end,
etc., is almost equal to that of the rest of the function.
∂25-May-83 1346 @USC-ECL,@MIT-ML:Moon%SCRC-TENEX@MIT-ML REDUCE Change
Received: from USC-ECL by SU-AI with TCP/SMTP; 25 May 83 13:46:28 PDT
Received: from MIT-ML by USC-ECL; Wed 25 May 83 13:04:52-PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Wed 25-May-83 14:26:32-EDT
Date: Wednesday, 25 May 1983, 14:20-EDT
From: David A. Moon <Moon%SCRC-TENEX@MIT-ML>
Subject: REDUCE Change
To: Bernard S. Greenberg <BSG%SCRC-TENEX@MIT-ML>
Cc: common-lisp%su-ai@usc-ecl
In-reply-to: The message of 25 May 83 13:29-EDT from Bernard S. Greenberg <BSG at SCRC-TENEX>
Date: Wednesday, 25 May 1983, 13:29-EDT
From: Bernard S. Greenberg <BSG@SCRC-TENEX>
What is the reason for this new wart in the definition of REDUCE, i.e.,
REDUCE of a one-element subsequence does not invoke the function?
Since the function is required to take two arguments, how could it be invoked
when there is only one thing to give it?
The bug here (I just looked at a recent version of KSEQUE.MSS) is that the
clarification note about one-element (sub)sequences should have said that
it only applies to the case where no :initial-value is specified. If a
:initial-value is specified, then the function is not invoked in the case
where the subsequence contains -zero- elements.
So far as I know none of this is new, it's just that the manual doesn't
explain it at all clearly.
∂25-May-83 1410 @USC-ECL,@MIT-ML:BSG%SCRC-TENEX@MIT-ML REDUCE Change
Received: from USC-ECL by SU-AI with TCP/SMTP; 25 May 83 14:09:45 PDT
Received: from MIT-ML by USC-ECL; Wed 25 May 83 14:10:20-PDT
Received: from SCRC-BORZOI by SCRC-TENEX with CHAOS; Wed 25-May-83 17:09:58-EDT
Date: Wednesday, 25 May 1983, 17:08-EDT
From: Bernard S. Greenberg <BSG%SCRC-TENEX@MIT-ML>
Subject: REDUCE Change
To: Wholey@CMU-CS-C
Cc: common-lisp%su-ai@usc-ecl, common-lisp-implementors%SCRC-TENEX@MIT-ML
In-reply-to: The message of 25 May 83 16:33-EDT from Skef Wholey <Wholey at CMU-CS-C>
Date: Wed, 25 May 1983 16:33 EDT
From: Skef Wholey <Wholey@CMU-CS-C>
My intuition about and implementation of REDUCE are exactly opposite yours, I
guess, since this special case does fall nicely out of my code.
I retract every(previous)thing I have said on the subject.
You (and Moon) are right, it falls out of my code too, I have been
away from my function too long...
∂25-May-83 1425 @USC-ECL:WHOLEY@CMU-CS-C REDUCE Change
Received: from USC-ECL by SU-AI with TCP/SMTP; 25 May 83 14:24:55 PDT
Received: from CMU-CS-C by USC-ECL; Wed 25 May 83 14:24:54-PDT
Received: ID <WHOLEY@CMU-CS-C>; 25 May 83 16:33:34 EDT
Date: Wed, 25 May 1983 16:33 EDT
From: Skef Wholey <Wholey@CMU-CS-C>
To: Bernard S. Greenberg <BSG%SCRC-TENEX@MIT-ML>
Cc: common-lisp%su-ai@usc-ecl,
common-lisp-implementors%SCRC-TENEX@MIT-ML
Subject: REDUCE Change
Date: Wednesday, 25 May 1983, 13:29-EDT
From: Bernard S. Greenberg <BSG%SCRC-TENEX at MIT-ML>
Re: REDUCE Change
It is not at all consistent with the rest of the definition of the
function. The specific (reduce '(foo) #'+) example in the manual
seems to me counterintuitive. I guess my big complaint is that this
"feature" does not fall out of the code nicely at all, and the amount
of code spent worrying about it, given indefinite list ends, :from-end,
etc., is almost equal to that of the rest of the function.
My intuition about and implementation of REDUCE are exactly opposite yours, I
guess, since this special case does fall nicely out of my code. If no initial
value is supplied, I grab the first (or last if we're :from-ending it) element
from the specified subsequence and restrict the bounds by one. Then I enter a
loop calling the function until the subsequence is exhausted. So the function
is never called. The case of passing in a null sequence with no initial value
is handled entirely separately. So
(reduce #'+ '(2)) <==> (reduce #'+ '() :initial-value 2).
--Skef
∂26-May-83 1016 FAHLMAN@CMU-CS-C Manual update
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 26 May 83 07:53:00 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 26 May 83 09:55:06 EDT
Date: Thu, 26 May 1983 09:55 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: common-lisp@su-ai
Subject: Manual update
For reasons too complicated to discuss here, progress on the Common Lisp
Manual has been rather slow lately. Guy and I have discussed how to fix
this, and we have decided that the best way to converge quickly is for
him to concentrate on editing in the relatively non-controversial things
and those items on which decisions have been reached, and for me to
orchestrate the arpanet-intensive process of reaching some sort of
consensus (or at least a decision) on those issues that still require
some debate. I will keep some sort of file on the decisions that have
been reached to date -- more on this in a later message. Guy will be
watching these debates and commenting where appropriate, but will not be
doing the day-to-day message answering.
Given the need to move fast on this, I do not propose to do this via a
single moby ballot. Instead, I will raise issues one by one or in small
groups, and will in most cases attach a strong recommendation or
proposal to each. People will have 48 hours or so to object or raise
counter proposals -- longer, of course, for the more complex issues.
Then a decision will be announced, will be put in some sort of file, and
will be turned over to Guy for inclusion in the manual. Implementors
should feel fairly safe in treating the things in this file as settled.
It will be possible to re-open issues after the gavel has come down, or
for that matter to re-open any old wounds, but the threshold for getting
a change adopted or even a fair hearing will be very much higher in such
cases. At that point, mere tastefulness (or lack thereof) will probably
not suffice -- only arguments of the form "The language cannot possibly
work if we retain X" or "X is unimplementable" or "X will be devastating
to potential users of Common Lisp" will be entertained at that point.
I will endeavor to strike a reasonable balance between speed and
decisiveness, on the one hand, and giving everyone a fair hearing, on
the other. If anyone thinks I'm drifting too far in either direction,
apply feedback.
Does anyone object violently to this new scheme? If so, speak now, but
be sure to include a viable counter-proposal.
-- Scott
∂26-May-83 2101 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN ENDP
Received: from MIT-MC by SU-AI with TCP/SMTP; 26 May 83 21:01:32 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Fri 27-May-83 00:03:48-EDT
Date: Thursday, 26 May 1983, 23:56-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: ENDP
To: common-lisp@su-ai
In-reply-to: The message of 26 May 83 22:49-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
I like Scott's wording better. However, I surmise that the use of the
vague expression "whether ... will behave reasonably ... depends on the
implementation" was intended to convey the idea that some implementations
will use a NULL check (rather than an ATOM check) and hence will behave
most unreasonably, cdr'ing off into randomness, when given a dotted
list. Of course this is discouraged, but the manual should say explicitly
whether it is allowed or forbidden. To summarize:
1. ENDP check (or NULL check plus always-error-checking CDR)
Error if given a dotted list and end of it reached
2. ATOM check
Dotted list simply behaves like an undotted one
3. NULL check
Dotted list causes unpredictable behavior.
∂27-May-83 0055 FAHLMAN@CMU-CS-C ENDP
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 26 May 83 19:47:51 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 26 May 83 22:49:13 EDT
Date: Thu, 26 May 1983 22:49 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: steele@CMU-CS-C
Cc: common-lisp@su-ai
Subject: ENDP
Guy,
In the DTYPES chapter (May 10) you say that functions that require lists
expect to be given true lists, but that "whether a function that
requires a true list will behave reasonably when given a dotted list
depends on the implementation".
I agree with the sentiment, but I would like to propose a rewording:
"It is an error to pass a dotted list to a function that is specified as
requiring a list argument. Implementors are encouraged to check for
this error by using ENDP (ref) to check for the end of the loop.
However, since this test is often part of an inner loop, it must be
efficient. Some implementations may choose to use ATOM for such tests,
quietly ignoring any non-null terminating atom."
Or something like that. All of our implementations are reasonable, but
on a Vax there's a limit to how reasonable you can be.
-- Scott
∂27-May-83 1022 RPG Comments on LASER.UPDATE
∂26-May-83 2227 STEELE@CMU-CS-C Comments on LASER.UPDATE
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 26 May 83 22:23:57 PDT
Received: ID <STEELE@CMU-CS-C>; 27 May 83 01:23:14 EDT
Date: 27 May 83 01:23:14 EDT
From: STEELE@CMU-CS-C
Subject: Comments on LASER.UPDATE
To: moon%scrc-tenex@MIT-MC, dlw%scrc-tenex@MIT-MC, declisp@CMU-CS-C,
fahlman@CMU-CS-C, vanroggen@CMU-CS-C, rpg@SU-AI,
guy.steele@CMU-CS-A
Here follows an annotated version of the file from MOON and DLW.
My comments are in braces. Most of it is well under control, but
there remain controversial issues as always.
--Guy
---------------------------------------------------------
File [CMU-CS-C]PRVA:<SLISP.SCL>LASER.REPLY
This file is a reply in the form of an annotated copy of LASER.UPDATE.
Annotations by Steele are in braces. Standard comments include:
{controversial} Requires more discussion, or is being discussed.
I don't want to decide this unilaterally.
{will fix} I will fix this (in some cases, have already fixed it).
{okay by me} This looks good, but I'd like confirmation.
{will clarify} I will improve the prose (or have already improved it).
This file contains comments on the Laser edition of the Common Lisp manual.
* means this is non-trivial or controversial.
[done] means this has been fixed in the latest (mid-May) version of the manual.
[not done] means it hasn't been.
[new] means this is a new comment on text not in the Laser manual.
[gloss] is new commentary resulting from new text not in the Laser manual.
Major issues are summarized at the end.
* 0: (everywhere) Why are there so many type-predicates? typep could just
as well be used, and has the advantage that you don't have to remember for
a hundred things whether each one is spelled "foop" or "foo-p". Why doesn't
the "setf argument" apply to type predicates as much as to storing functions? -- Moon
{controversial}
9: |P 1: 'consititutes' -- Moon [not done]
{now done}
14: |P 4: says erroneously that a decimal point is required. The BNF and
the examples are consistent and correct. -- Moon [done]
15: |P 1: the default value is 'single-float', not 'single'. -- Moon [done]
15: disagrees with p.34 about whether the type is (complex t1) or (complex t1 t2).
Also the eql identities on p. 15 prohibit floating-point contagion between the
real and imaginary parts, which might be both useful to the implementation and
numerically valuable. I.e. (complex 1/3 0.5) could not float the 1/3. -- Moon [not done]
{On page 34 it is noted that (complex x) is defined to mean the same
thing as (complex x x). Will clarify.}
* 17: |P 5: do not include ! and ? in the list of alphabetics, since they are
reserved to the user. They default to alphabetic but are likely to be changed. -- Moon
[done]
18: Neither the text nor the examples shows that \ before a letter suppresses
case-conversion. Both should. -- Moon [done]
* 19: |P 4: If most functions advertised to work on lists will work on dotted
lists, then no one calls the ENDP predicate. I've complained about this before.
Possibly the right thing is to avoid the word "list" here, and add an explicit
discussion of the distinction between trees and sequences.
Which way is our policy? -- Moon
[done]
[gloss] The data type chapter now says that functions advertised to work
on lists require true lists, and whether they behave reasonably when
given a dotted list depends on the implementation. So I guess this means
they are allowed to do any damned thing they please. We will error on
dotted lists either by using ENDP or by virtue of our full-error-checking
CDR instruction.
19: In the second example, change "a list of three" to "a dotted list
of three"; in this context it is important to make the distinction. -- DLW [done]
20: The last line uses the term S-expression. I belive we have formally
agreed to abandon this term; I really don't like it, and you don't even
explain it anywhere. "a one-dimensional array of Lisp objects" should
be used instead. -- DLW [done]
20: |P 2: 'in in' -> 'is in' -- Moon [done]
21: The last sentence of section 2.5.2 ("this syntax") is a non-sequitur,
put it in a different paragraph (not necessarily its own separate one). -- Moon [done]
* 21-22: Be specific about the order in which the character are stored
into the string, and that the bits are stored into the bit string,
particularly the latter. Is (aref #*10110 0) zero or one? -- DLW [done]
22: S 2.10: 'Nearly all function' -- Moon [done]
25: 'hash-table' but 'readtable'. I guess it's too late to try to regularize
everything. -- Moon
{Yep, that bugs me too. Too late.}
25: you imply that no new subtypes will ever be added to 'common'. The right
thing to say is that no implementation may unilaterally add subtypes to common,
however future extensions to the Common Lisp manual may. Also you defined
it in such a way that (array t) and (complex t t) are not subtypes of common!
This was clearly not what you meant to say. (In fact, if you think about it
more the one essential difference between Lisp and Ada (or Pascal) is that in
Lisp it is meaningful for (array t) to be a subtype of common although t itself
is not. Well, there are about two other essential differences...) -- Moon [done]
* 25: allow package to be a subtype of hash-table (although it won't be in
ours, most likely) -- Moon [not done]
{In my opinion this is a bad idea.}
27: this section is very confusing because it isn't made perfectly clear that
'entities' includes both 'names' and 'objects'. Covering both in one set of
rules is nice, but they are really very different. Also you need a note
pointing out that parallelism is not addressed by this standard and implementations
that add extensions for parallel processing with shared objects (this could be
coroutines, multiple processes with asynchronous process switching, or
multiple hardware processors) will have to define for themselves what dynamic
extent and dynamic scope mean. In the Lisp machine dynamic extent means what
the first sentence in your definition says, while dynamic scope means dynamic
extent and usually indefinite scope -within- a single process, although there
are constructs (LET-GLOBALLY) where it means indefinite scope across all processes.
But an S-1 multiprocessor would have real trouble confining scope of some things
to a single process. -- Moon [not done]
{Will clarify and add examples.}
28: The compose example won't work. You need "funcall" in two places.
Sorry, this isn't Scheme... -- DLW [done]
29: |P 3: 'possibility is shadowing' -- Moon [done]
* 29: Are special variable bindings captured by function closures? Does it
make a difference whether the closure has been passed "upward" out of the
dynamic extent of the binding? In Sussman's "unwind-protect" semantics,
special bindings are not captured by function closures, which seems like
a fatal crock from the user point of view ("why should declaring a variable
special make it disappear completely?") On the other hand, if function closures
do capture special bindings when used "downward", undesired behavior can
occur. Since upward funargs are a new language feature, I think it is best
not to capture special bindings. This is what your current text implies, but
you need to be explicit about this, even though I don't think your
conceptual structure in this chapter can express the distinction. In any case,
catches (which also have dynamic scope) should -not- be captured by closures! -- Moon
[not done]
{It is intended that specials not be captured. A careful reading of
Chapter 3 will produce this information: special bindings have dynamic
extent, period; therefore they cannot be captured. Examples and additional
clarification will be added.}
* 32: keyword should be a subtype of symbol; this would often be used with
typecase. -- Moon [not done]
{okay by me}
32: Table 4-1 is in the wrong place. Also I think you should flush the cute
but non-obvious order and alphabetize it. -- Moon [not done]
{okay by me}
* 32: Re the query: Yes, it should be defined to be in the obvious
order, rather than left to the implementation, for the reason you say. -- DLW [not done]
{okay by me}
* 32: (the query about and/or type expressions). The last sentence on p.31 says
that these predicates should not have side-effects, however as you point out
errors are side-effects. People will expect the and/or type expressions to
have the same evaluation rules as the and/or special forms, and that is easy
to do and useful, so I think it should be done. If not, the type expressions
should be renamed to intersection and union to avoid the implication from and/or. -- Moon
[not done]
{okay by me}
* 33: Since "typep" means "can the array ONLY hold this type", is there
a way to ask "is the array CAPABLE of holding this type", which would
return T for both A and B? I brought this up last time but can't
remember if I ever got an answer. -- DLW [not done]
{To ask "can array A hold an element of type B?" say
(subtypep B (array-element-type A))
This is the precise reason that array-lement-type was introduced.}
33: The text should explicitly say what "*" means; you shouldn't hear
about it in the examples first! Also say explicitly somewhere that the
lists are allowed to be shorter: that is, a vector type spec is (VECTOR
<element-type> <size>), but (VECTOR T) is OK even though it does NOT fit
into that pattern. Say it in the text, not just in the examples; this
is a language definition. -- DLW [not done]
{It is stated in |P 3 on page 31. This paragraph should be broken
out into a separate section and expanded upon.}
* 33: So what is the difference between (ARRAY *) and (ARRAY T)? Why is
it a subset? Please elaborate on this point, in the manual. -- DLW [not done]
{okay by me}
36: In the definition line, "lambda-list" => "varlist". (Page 99 too.) -- DLW [done]
37: cute notes for coerce: (coerce x t) <=> (identity x). (coerce x 'common)
means something but I can't figure out what. (coerce x nil)
is always an error (say more explicitly whether coerce signals an error). -- Moon [not done]
{okay by me}
* 37: What is the order of arguments to coerce? Once in the text you have
the type first; this may actually be the right thing, since most other functions
(except TYPEP) that take a type put it first, and the analogy with THE actually
makes a lot of sense. Also cross-reference THE here. -- Moon [not done]
{controversial}
* 38: Coercing of characters to integers should probably be allowed too. -- DLW [not done]
{controversial}
38: At the top of the page, what is ,=> ? -- DLW [not done]
{Typo; should be no comma.}
39: "S-expression" again. Use "Lisp object". -- DLW [done]
40: This section (5.1.2) really must explain the concept of an "unbound"
variable. -- DLW [not done]
{okay by me}
41: 'and' and 'or' can be defined in terms of 'cond', so why are they special
forms if 'cond' is a macro? If it's because the expansion into 'if' of the
form of 'cond' that 'or' turns into is incredibly clumsy, then 'cond' should
be a special form also. -- Moon [not done]
{I think this is partly a remnant of the discussion on multiple values.
Now that AND and OR have been clarified, I could go for making AND and OR
be macros, but making COND a special form would also be acceptable.}
* 41: The paragraph in the middle starting "an implementation" is vague.
It is never explained how one goes about providing an "equivalent macro
definition". What is the implementation restricted to do regarding, for
example, FSYMEVAL of special-form-naming symbols? This whole idea about
limiting the number of special forms and letting the implementation use
macros, but still be able to implement things as "quoted args"
functions, needs to be explained better, and the restrictions on the
result of FSYMEVAL need to be defined. -- DLW [not done]
{will clarify}
42: At the bottom, it should mention FLET too. -- DLW [not done]
{okay by me}
* 42: At the top, if "the expansion need not be.", then it is not clear
to me that one can write a portable code-walker, since it may run into
implementation-specific special forms! -- DLW [not done]
{I think we should limit this to forbid impl-dependent special forms
in this case. My intent was to permit impl-dependent functions.}
* 42: |P 1: It's useless to make most special forms be macros for the benefit
of program-understanding programs, so that those programs don't have to have
special knowledge of them, if the macros expand into implementation-dependent
code that those programs can't understand! This is especially bad when you
consider the omnipresence of SETF. I'm not sure what to do here, since it
is probably important to allow the macro expansion to be implementation dependent
for certain of these. -- Moon [not done]
{See previous remark.}
* 44: The rationale note: how so? If the compiler sees an arbitrary
form where it expects a keyword, well, how does it know that form
doesn't evaluate to a keyword symbol? Surely you aren't suggesting that
this be illegal? That would be no good at all. -- DLW [not done]
{In some situations type analysis will reveal that the arbitrary
form cannot produce a keyword. Simple example: a quoted expression
or number. For example, the compiler could catch (fill x y 0 5),
which should be (fill x y :start 0 :end 5).}
46: The value of 'x' is out of order in all the mixture examples -- Moon [done]
46: The examples of mixtures don't work. The bodies should be (list a b x c d)
to make them correct. -- DLW [done]
47: S-expression again. -- DLW [done]
48: The caveat about use at top level is given twice, inconsistently,
and only about DEFVAR and not the others. -- DLW [not done]
{will fix}
* 48: p.48 and p.79 disagree about whether DEFUN puts in a block named NIL
in addition to the block named the same as the function. Perhaps the mention
of RETURN on p.48 is just a typo. I could live with it either way. -- Moon [not done]
{will fix}
49: Re defconstant, you say "an error occurs". It is completely unclear
whether this means that "it is an error" or "an error is signalled".
Stick to your defined terminology. -- DLW [done]
49: The example is bad: in this case, DEFCONSTANT would be more
appropriate. Find something more variable. -- DLW [not done]
{will fix}
49: In eval-when's definition line, "situation" is in the wrong font. -- DLW [not done]
{will fix}
49: eval-when says that all top level forms are by default effectively wrapped in
(EVAL-WHEN (EVAL LOAD) ...). This isn't true; macro definitions and declarations,
and several other things one could list, happen at COMPILE time too. -- Moon [not done]
{will fix}
* 49: DEFCONSTANT claims to have an error (not to signal one?) if it is done
twice and the values aren't EQUALP. But EQUALP ignores alphabetic case. I
think this error check should be flushed; after all, DEFMACRO doesn't signal
an error if you redefine a macro to be something that generates different code.
Also use stars in the DEFVAR example.
Also add a note saying how to define a documented variable without giving it
a value (SETF of DOCUMENTATION I guess, bleagh). -- Moon [not done]
{Will fix. I guess I am content to not have an error check.
We never did some up with a good way to document without giving a value.
Maybe we really should go to a keyword syntax. Bawden, I think, noted that
"=" could be a keyword: (defvar x := 5 :documentation "foo") ???
But I think this is a bit too precious.}
51: [gloss] "p" vs "-p" rule for predicates documented.
51: I thought we voted to get rid of the term "pseudo-predicate". I
mentioned this last time. I guess I don't care, but I should point out
that you don't get much use out of this term in the rest of the manual. -- DLW [not done]
{will fix}
52: It says [NIL NIL, which appears to be a typo. -- DLW [done]
52: TYPEP shouldn't allow (VALUES ...) type specifiers, either. -- DLW [not done]
{will fix}
53: (TYPEP X '(CONS NULL)) is missing an "OR". You know, someone really
ought to run these examples... -- DLW [not done]
{will fix}
53: (under listp) '(cons null)' -> '(or cons null)' -- Moon [not done]
56: In the implementation note: "implemnetations" is a misspelling. -- DLW [done]
58: the nonexistent functions 'vref' and 'lessp' are used in two examples -- Moon [not done]
{will fix}
59: (and) <=> t, not just true, right? -- Moon [not done]
{okay by me}
62: In QUOTE, "the argument" should be @i[object]. It's misleading
to call it an argument, since it really isn't one. -- DLW [not done]
{will clarify}
63: Under symbol-function, it sounds like you can take what it returns and
pass it to macro-p and special-form-p. However, those functions are documented
to demand a symbol. Probably this is not a language problem, the manual just
needs to be clarified. -- Moon [not done]
{will clarify}
63: At the top, why does it say "(normally)"? I guess this means that
you might manually alter it? Probably "it is an error" to do so. -- DLW [not done]
{will clarify}
63: [gloss] macro-p renamed to macrop
64: In SETQ, you use the verb "assign to" backwards. The variable
is assigned; the value is not assigned. -- DLW [not done]
{will clarify}
65: FSET should be flushed with all the other update functions, in favor of
(SETF (SYMBOL-FUNCTION x) y). The word FSET could easily be confused
with SETF. --Benson [not done]
{will fix}
66-67: In the enumeration of legal SETF forms, you forget to
mention "anything done by DEFSETF". -- DLW [not done]
{will fix}
* 67: In SUBSEQ: is the replacement value restricted to be the same
length as the subsequence? Probably it should be. -- DLW [not done]
{will clarify}
68: In the SETF example, you don't even use G1 and G2 at all... -- DLW [done]
68: In SHIFTF, you might as well use the syntax {place}+ instead of
place {place}*, as long as you went to the trouble to define +. -- DLW [not done]
{will fix}
69: 'exchf' -> 'rotatef' -- Moon [done]
70: Moon's DEFSETF proposal [not done]
{okay by me}
70: rotatef in wrong font (at top of page) -- Moon [not done]
{will fix}
* 70: The documentation for defsetf is inconsistent about who is responsible
for ensuring proper order of evaluation. The text says that the defsetf body
is responsible for this, but the examples show SETF itself introducing
variables bound to all relevant things. Doing it the latter way is probably
better, because it makes it possible for macros such as PUSH to evaluate
arguments only once. But it requires that the implementation recognizes when
a variable is unnecessary and optimize it out (since it is impossible for the
defsetf body to do this itself), and requires you to resolve the issue of DEFSETF
on a special form (rather than a function), which is a reasonable thing to do
but introduces the need for the defsetf body to see actual pieces of the form,
rather than variables that are bound to the results of evaluating arguments of
the form. This is vital, but I don't have a suggested solution yet.
If you would put function specs into the language then you could document the
name of the function created by the complex form of DEFSETF, and then tools
such as TRACE could be used to debug it. -- Moon [not done]
{controversial}
* 71: (query) I think MMcM had a proposal about this. Need to check. -- Moon
* 71: The query: good problem. Make it legal to pass unknown keywords?? -- DLW
{controversial}
71: |P 2: 'arguments...consists'. -- Moon [not done]
{will fix}
* 71: Is APPLY's second argument required? What if you want to apply
something to no arguments? -- DLW [not done]
{will fix}
71: In the middle, "lista rgument" is a typo. -- DLW [done]
73: The syntax for LET and LET* is given twice, and one copy omits declarations -- Moon
[done]
73: In LET: you use both "varj" and "bodyj". In the Lisp Machine Manual,
we'd use "i" for one and "j" for the other, to clarify the fact that
they aren't don't have the same index set. -- DLW [not done]
{will clarify}
74: COMPILER-LET has to be a special form, not a macro, right? -- DLW [not done]
{will fix}
74: |P 5: 'let' -> 'let*' -- Moon [not done]
{will fix}
74: compiler-let cannot be written as a macro. It must be a special form. -- Moon [not done]
{will fix}
* 80: If 'loop' does not establish a block, then you must name it something
else, since it then cannot be extended into the full loop construct.
Also the rationale about loop vs tagbody is bogus, since a tagbody that
contains only one label and only one go, at the end, is easily recognized
(any time after macros have been expanded). -- Moon [not done]
{Okay, how about if the simple form establishes a block named NIL?}
80: In 7.8, when you say "All of the interaction constructs permit",
you should except LOOP. -- DLW [not done]
{See above.}
87: |P 4: 'A tag are' -- Moon [not done]
{will fix}
* 87: a tagbody that drops off the end should return the value(s) of the
last form, rather than nil, since many applications would otherwise need
to wrap a block around it; a simple looping construct that turns into -- Moon [not done]
(TAGBODY initialization NEXT iteration END return-value) is an example.
{Controversial. What is the value in the case
(TAGBODY form1 form2 tag) ? The value of form2, in the drop-through case?
What about when one does a GO to the tag?}
* 87: Make it very explicit that GO can be from an internal procedure,
and that you can GO through a catch. Can you GO from "under evaled
arguments" (that is, (list a b (go foo)), for example)? We should be
very explicit about this: don't try to hide the "dirty laundry" here,
because the result is that people will launch on implementation without
realizing important things about the run-time requirements. It's
important to keep the implementors in mind, when you're writing the
language definition. -- DLW [not done]
{Will clarify. There's already an example in chapter 3, but I'll add
cross-refs and more examples.}
89: |P 7: multiple-value-call and multiple-value-prog1 are receivers too. -- Moon [not done]
{will fix}
89: Document that (VALUES (FOO)) is the preferred way to ensure that exactly
one value is returned. -- Moon [done]
90: 'the the' -- Moon
{will fix}
91: (4th bullet) MULTIPLE-VALUE does not have an implicit PROGN. -- Moon [not done]
{will fix}
91: The list of implicit-progn functions should not include
multiple-value. -- DLW [not done]
{will fix}
* 91: In MULTIPLE-VALUE it is useful to have a way to discard unwanted values.
Since you aren't binding, using an ignored variable is inconvenient. The
Lisp machine uses NIL in place of a variable to mean "ignore this". For
consistency NIL should work in MULTIPLE-VALUE-BIND also, although it is
less essential there. -- Moon [not done]
{controversial}
* 93: Under CATCH it says that any Lisp object may be used as a tag, however
on page 94 it says that UNWIND-ALL uses NIL as a special-case flag. Thus
anything that throws to NIL, with an UNWIND-ALL between the throw and the
catch, will be screwed since the throw will not be relayed. I still maintain
that CATCH-ALL and UNWIND-ALL are worthless and should be flushed. -- Moon [not done]
{controversial}
93: CATCH deserves a compatibility note re Maclisp. -- DLW [not done]
{will clarify}
93: Hyphens are missing from CATCHALL. -- DLW [done]
94: Clarify that UNWIND-PROTECT protects against lexical exits (GO, RETURN,
and RETURN-FROM) as well as dynamic exits (THROW). -- Moon [not done]
{will clarify}
97: The syntax for MACRO is given twice, the two copies are inconsistent, and
both are wrong (neither includes documentation strings). This problem is
endemic in the special forms and should be fixed in a uniform and consistent
way. I suggest defining some abbreviations to be used in the function headers,
documenting them in the notation section, and using them consistently, and also
fixing all the fully-spelled-out syntax descriptions in the bodies of function
descriptions. For instance, you might make up a word such as 'dbody' that means
a body optionally preceded by documentation and declarations. Shades of Algol 68,
unfortunately. -- Moon [not done]
{will clarify}
97: S-expression again. -- DLW [done]
97: MACRO cannot be implemented as a macro, since it is the primitive for
defining macros and there is nothing for it to expand into. Unless it expands
into something outside the language, in which case it is useless for it to
be a macro rather than a special form. Compare my comment on p. 42. -- Moon [not done]
{It can expand into calls on implementation-dependent functions.}
99: lambda-list => varlist -- DLW [not done]
{will fix}
* 99: "destructuring" defmacro is essential! The reason the argument about
paralleling defun is utterly bogus is that destructuring defmacro is used when
defining special forms, whereas defun is for defining functions. It is quite
desirable for special forms to use parenthesization in their syntax. Enhancing
the confusion in a difficult area for new users by confusing functions and
special forms in the notes in the manual is hardly a good idea. -- Moon [not done]
{controversial}
100: "environment" => "env". Make the cross reference to *EVAL, not
to EVALHOOK, since EVALHOOK just refers you to *EVAL. -- DLW [done]
101: (Moon's proposal to have a PROCLAIM function and make the DECLARE
magic-syntax not be allowed at top level). [not done]
{controversial}
102: |P 2: 'keyword' -> 'symbol'. Names of declarations are not in the keyword
package, and should not be. [done]
Also this paragraph needs to be made to avoid confusing the reader by making
him think that SPECIAL declarations are not pervasive (explained on the next
page). -- Moon [not done]
{will clarify}
* 102: |P 5: This paragraph is -totally- random. Especially the weird exceptions
('for variables not bound by that form' [although since it is ambiguous which
of the two forms being discussed you are referring to, maybe I just made the
wrong choice of form and this one isn't so weird], 'except for the first
initialization form'). It would make a lot more sense to adopt the following
rule, even though it means that LET isn't a macro that expands into a LAMBDA
combination (unless one with no arguments that uses &AUX as a trick). -- Moon
Code used to compute initial values for bound variables in a
variable-binding special form is included in the scope of pervasive
declarations at the head of the body, in all cases.
Such code does not see non-pervasive declarations
in the body when the scope of the variable binding such a declaration
is attached to does not include that code (of course).
This is much better than forbidding pervasive declarations except for a bunch
of exceptions that you discover you need in order to write programs. [done]
* 103-105: The meaning and scope of global declarations in the Lisp
Machine is unclear. A top-level (declare (optimize ...)) probably wants
to apply only to the file in which it appears, whereas a top level
(declare (special ...)) has to side-effect the global environment and
persist after the file is loaded. -- DLW
{controversial}
* 103: The note about how LOCALLY "cannot be used meaningfully for
declarations of variable bindings" is not completely clear. I first
thought this meant that you couldn't do SPECIAL declarations in LOCALLY
because there are no bindings, but the first example on page 104 does
so. What is this sentence trying to say? -- DLW [done]
103: (under locally) '(optimize' -> '(declare (optimize' -- Moon [done]
103: It should be mentioned in the description of the SPECIAL declaration
form that DEFVAR is the recommended way of declaring a special variable.
--Benson [not done]
{will clarify}
104: 'name' appears spuriously in the ftype equivalent of the function
declaration. -- Moon [done]
* 106: Because of the "declaration" declaration, we must define declarations
to be processed in serial! -- DLW
[gloss] he changed the manual to say that this declaration may only be used
at the top level of a file.
107: I've been burned at least three times tonight by the fact that the
symbol chapter refuses to admit that section 7.1.1 (on value and
function cells) exists. There should be some kind of cross-reference,
since I keep forgetting how to do fsymeval. --Moon [not done]
{will clarify}
* 108: Re the query: I think "it is an error". -- DLW [not done]
{okay by me}
109: 'getf' in wrong font (first word in its description) -- Moon [done]
109: SETF of an entire property list should be strongly discouraged,
since the system itself, or other packages, may be using the property
lists of any symbol. -- DLW [done]
* 109: why wasn't putf flushed when putprop was? -- Moon [not done]
{okay by me}
109: PUTF should be flushed, since (SETF (GETF x y) z) works equally well.
--Benson [not done]
110: symbol-print-name should be called symbol-name. --Moon [not done]
{will fix}
110: The compatibility note about samepnamep on the Lisp machine is false.
I have pointed this out before. -- Moon [done]
* 110: I see nothing to be gained by not defining the order of search in
get-properties. It's not like the implementation is allowed to use a hash
table for a property list, since get-properties takes a place argument
and what the contents of that place can be is strictly specified. It
should be defined to return the property closest to the front of the list
being searched. -- Moon [done]
110: [gloss] Third value of get-properties changed to be like GETL's value.
111: Sec 10.3, in |P 4, "an uninterned symbol prints in the same way as ..."
is not true; it uses #:. (This was pointed out to me by Bob Cassels of
Symbolics; apparently neither Moon nor I caught this.) -- DLW [done]
[Note: package chapter not reviewed since Fahlman's replacement will be installed]
* 115: You need a description here of the concept of a "package name".
Names should be strings, not symbols.
{okay by me}
A more serious question: what is the value of (symbol-package 'car)
allowed or restricted to be? The ploy of saying that making a new
package semantically does a copy looks like it is intended to allow us
to share, but this doesn't really work in the presence of side-effects
on the copied/shared package, which you can get from INTERN and
UNINTERN. EXPORT copying into the USER package, for example, is
really wrong.
I'd like to see a complete example of how a tiny yellow-pages program
would be written, using this facility. I'm not convinced that it
can be done! -- DLW
{It is important to have such an example in the manual, of a full
but small yellow-pages facility, if we can possibly manage it.}
115: Why allow *package* to be bound to a name? This is just extra
complexity and inefficiency for no gain. -- Moon
{okay by me}
117: naming packages with symbols rather than strings cannot work. In what
package is the symbol returned by package-name? It can't always be in the
one the caller expects unless it is global (not shadowed by anyone) or always
referenced with a package prefix (a keyword for instance). Save yourself
a lot of problematic interactions by making them strings. -- Moon
{okay by me}
* 118: The two symbol case of EXPORT, which calls UNINTERN, cannot work
in any system where compiled files intern symbols only once and then look
them up in a table, as is true of most "fasload" schemes. Perhaps this can
be kludged by allowing EXPORT only at top level and having the compiler
kludgily convert the arguments from symbols to strings. This applies to
SHADOW also. Furthermore this whole mechanism will collapse if you try to
add inheritance to it; it is okay as a "clumsy obarray switching" scheme,
but cannot "accomodate experimentation with extensions." Probably the best
thing is to document this as purely an interim kludge, rather than as the
foundation of what Common Lisp will have eventually. -- Moon
Actually, things are much worse than that. By trying to avoid taking a stand
on inheritance, this package system has the worst possible form of inheritance
(namely copying). The fundamental business of a package system is to provide
easy and robust ways of controlling when the same name in two different contexts
gives the same symbol and when it gives two different symbols. By making the
USER package (the one that programs are loaded into by default and typed input
is interned in by default) be the package from which all other packages inherit
(by copying it at the time they are created), the accidental-sharing bug is
maximized: whether two packages share the symbol X or have each their own private
symbol X depends on whether the user happened to type an X before loading those
packages. It isn't reasonable to require a SHADOW declaration in every package
of every symbol other than those that are explicitly imported from the Common
Lisp language itself and from other packages.
By using copying rather than a more dynamic inheritance, the
accidental-shadowing bug is maximized: If package A depends on something
exported by package B, but package A is loaded first, then when package A
copies the user package, package B's exported symbols have not been placed in
the user package yet (unless it happened by coincidence that some third
program, already loaded into the USER package, had interned those symbols).
Thus package A gets its own private symbols by those names. Later, when
package B is loaded, the system has no way of knowing that those symbols in
package A were supposed to have been the same symbols. A related screw is
that because there are all these copies, it is maximally difficult to patch
things up if you discover that you made a mistake; for instance, if you want
to export another symbol from a certain package.
If you consider the example of mutually-recursive modules given on page 292,
there is no way to implement this using the package system, other than by
putting in explicit calls to INTERN to place symbols in other people's packages.
This is basically due to the copying form of inheritance.
A possible way to make this package system workable as an interim substitute
for a "real" package system, with only minor tweaks, is to eliminate the
copying form of inheritance, and instead to use the searching form of
inheritance, adding the notion of each package having two sets of symbols, the
internals and the externals. There cannot be two different symbols with the
same name, one in the internals of a package and one in the externals of the
same package. The EXPORT statement declares the externals, moving symbols
there from the internals. Furthermore it is possible to declare the externals
of a package separately from creating the package and loading code into it,
i.e. separately from doing any INTERN operations, i.e. separately from binding
any names to symbols. INTERN with respect to a certain package searches its
internals and externals, and then searches the externals of all other
packages, including Common Lisp itself (or alternatively, searches a list of
externals defined when the package is created). It is important to note that
this is only a description of functional behavior, not of the implementation.
For example, there are at least two ways of implementing this searching
behavior that do not require INTERN ever to make more than a single hash-table
lookup. Then one must decide the following issues:
- is it an error for more than one package to EXPORT the same symbol,
and if not do they share one symbol or do you get multiple external
symbols with the same name, so that the order of searching externals
of packages in INTERN matters?
- if package A has a symbol FOO in its internals, and inherits from
package B, and then package B exports the symbol FOO, what happens?
And what if there is more than one internal FOO already?
- what syntax and arrangement of files and of compilation do you use
to take advantage of the fact that you can preload the EXPORT statements
of mutually-recursive modules before loading the modules themselves?
- how do package prefixes fit in?
I have not worked out the details of this, so I don't know whether it is
completely workable. However this is a subset of the future Lisp machine
package system plans.
-- Moon (after discussion with Bawden)
119: Missing hypens in resultform. -- DLW
{will fix}
122: (introductory sentence of 12.2) 'signal an error' -> 'are an error'. [done]
The arithmetic primitives should not be required to have run-time error
checking on impotent machines. Also it says they work on all types of
numbers, but most of them do not work on complexes. What values do the
comparison functions return when given only one argument? They should
either require at least two or the boundary-case values, which are
non-obvious, should be given explicitly. -- Moon [done]
123: The definition of (= 3 3.0) should not be hidden in a compatibility
note! Be explicit about this in the main-stream text. -- DLW [not done]
{will clarify}
124: When you talk about "required coercions", you really have to define
just what these coercions are and what the rules are. For example, what
happens when a rational meets a float (presumably you get a float of the
same precision, but this isn't written down anywhere that I can find). -- DLW [not done]
{will clarify}
125: Likewise, the "rules of floating-point contagion" are referred to,
but those rules aren't written up anywhere. -- DLW [not done]
{will clarify}
127: "All produce floating" is not really true: (expt 3 5) surely
produces an integer. Is (log 8 2) => 3 or 3.0? What about (sqrt 4)?
This needs to be more explicit. -- DLW [done]
127: (exp) 'number' should be in italics -- Moon [done]
127: [gloss] (sqrt -9) is explicitly required to return a complex number
(not error). This is probably a loss (we've been through this many,
many times before...)
128: Say explicitly what the phase of a non-complex number is. -- DLW [done]
136: [gloss] remainder has been renamed to rem
137: float-fraction is referred to twice in the text; presumably
this is a typo. -- DLW [done]
137: 'fraction' or 'significand'? Text is inconsistent -- Moon [done]
* 137: You have not provided any way to extract the fraction/significand
of a float as an integer, except perhaps by the kludge of taking NUMERATOR
of RATIONAL, or by taking FLOOR of SCALE-FLOAT of FLOAT-FRACTION by a magic
number. Add a function to do this, and a companion function (or a second
value) to get the corresponding exponent, which differs from FLOAT-EXPONENT
by the magic number. -- Moon [done]
138: Specify that all arguments to these functions must be integers. -- DLW [done]
139: Delete the word commutative, it is irrelevant and furthermore two of
the functions you claim are not commutative in fact are. -- Moon [done]
142: 'byte' appears in italics when it should be bold three times on this page
(the other three times are correct) -- Moon [done]
147: The arguments to - in the Lisp-code definition
of short-float-negative-epsilon in the Laser edition are backwards--Moon [not done]
{will fix}
150: [gloss] standard-charp renamed to standard-char-p
graphic-charp renamed to graphic-char-p
string-charp renamed to string-char-p
alpha-charp renamed to alpha-char-p
uppercasep renamed to upper-case-p
lowercasep renamed to lower-case-p
bothcasep renamed to both-case-p
digit-charp renamed to digit-char-p
150: How is alpha-charp affected by bits and fonts? -- DLW [done]
* 150: Say explicitly how fonts and bits affect alpha-charp and xxxcasep.
It's hard to tell but it appears the intention is that bits must be zero
and any font restriction depends on the implementation. -- Moon [done]
151: 'i' -> 'j' in the example, and 'string-length' -> 'length' -- Moon [done]
152: How is char= affected by bits and fonts? -- DLW [done]
* 155: The effect of char-upcase and char-downcase should be allowed to
depend on the fonts and bits in an implementation-dependent way. For instance,
in the Lisp machine characters with non-zero bits do not have alphabetic case
in the same way that graphic characters do. -- Moon [done]
* 155: The examples for digit-weight call it digit-char. I prefer the
latter name, since what it returns is a character. The name digit-weight
could easily be thought to have the functionality of digit-charp. -- Moon [done]
156: Are the symbols returned by char-name in the keyword package? -- DLW [not done]
{will clarify}
* 156: (char-name) Why are the names symbols, rather than strings? Since
most of the names are implementation-defined it seems unlikely that people
should be encouraged to do EQ testing on character names rather than EQL
testing on character objects. What package are these symbols in? For characters
with bits, does char-name stick on "control-" prefixes, or is there another [done]
function to do that? And how do you tell it whether you want "c-" or "control-"? -- Moon
* 157: why isn't set-char-bit superseded by setf and/or make-char? Is it
because of wanting to change a bit in a character without doing an assignment
of the result? -- Moon
[not done] (but the function is reasonable I guess)
{You guessed it.}
* 160: |P 2: :from-end should be explicitly specified not to guarantee that
the :test function sees the sequence elements in any particular order, such as
the opposite order as it would without :from-end. In general test functions
with side effects should be discouraged. On the other hand, those sequence
functions that take explicit functional arguments (not :test/:key/-if/-if-not)
should allow side-effects in that function and guarantee the order of calls.
This applies to map, some, every, notany, notevery, and reduce. This means
that reduce is the only sequence function where :from-end has a guaranteed
effect on side-effects, rather than just controlling the form of the result.
The manual already guarantees this except that for reduce it is not 100% clear. -- Moon
[done]
162: The second |P under concatenate is nonsense, probably left over from the
days before it took a result-type argument. -- Moon [done]
164: Explaining that the what the reduce function does is to reduce the
sequence is less than illuminating if you've never seen APL; this use
of the word "reduce" is highly specialized jargon. Also, what if the
subsequence has only one element? Give some examples with subsequences
that are one and zero elements long. -- DLW [done]
* 164: Should there be a more concise way to do
(reduce '(lambda (x y) (union x y :test #'pred) seq)
It would be wrong for reduce to pass on unrecognized keywords to the
function, I think, even though that work in this specific case. -- Moon [not done]
{controversial. I don't think this should be addressed. That's what
lambda is for.}
164: (reduce) clarify that if the number of elements (in the sequence and
the initial value) is 1, the function is never called and that one element
is the result. -- Moon [done]
165: |P 1: refers to the ':start' keyword, which replace does not accept -- Moon [done]
* 166: remove-duplicates and delete-duplicates need :key
I think it should be defined by the language whether the first or the last
representative in the sequence of an equivalence class is retained (you can't
tell with the default test, EQL, but in general it makes a difference).
One way to do this is to say that by default it keeps the last representative,
but with the :from-end keyword it keeps the first. Defaulting to the last
might be weird, but it is more consistent with the pseudo-english
"remove-duplicates :from-end". -- Moon [done]
* 166: There should be a way to substitute for subsequences as well as for
single elements as SUBSTITUTE does. --KMP,Moon [not done]
{controversial and hairy}
* 167: nsubstitute may as well guarantee that the result is eq to the argument,
since I can't imagine any implementation in which this would not be true.
(If it was a tree operation rather than a sequence operation, such that it
could replace conses in the backbone of the structure, there would be an issue.) -- Moon
[not done]
{controversial. I see no need for a special-case guarantee here.
Parllelism is more important.}
168: add a note explaining why COUNT accepts a :from-end keyword. -- Moon [done]
168: (BSG's note that maxprefix,maxsuffix,mismatch are redundant)
[done] [not done] [text clarified but there are still all three functions]
169: stable-sort contradicts the statement on p.159 that variants are named
by adding suffixes. But don't rename it! -- Moon [done]
169: 'search-from-end' -> 'search when :from-end is specified' -- Moon [done]
169: it doesn't say what :from-end does for maxprefix and maxsuffix. I could
imagine it transforming one into the other, or I could imagine it merely
contradicting the last paragraph in the description, where it says the order
of matching is undefined. -- Moon [done]
170: |P 1: 'the function k' -> 'the :key argument' -- Moon [done]
170: 'above two expression' -- Moon [done]
170: |P 4: define what it means for the predicate to consider two objects equal,
in case some readers can't figure it out. It's (p x y) = (p y x) = nil. -- Moon [done]
171: (under merge) 'the function k' again -- Moon [done]
171: [gloss] merge has a new first argument, result-type.
174: (tree-equal) it says that equal recursively compares structured objects.
This is only true for strings and bit-vectors according to p.56. -- Moon [done]
175: [gloss] definition of endp fixed to be true of nil and false of conses
(it was backwards, but we didn't notice)
175: [gloss] optional second arg to list-length flushed. Instead it is required
to return nil if the list is circular. [Was this voted on????]
{Not voted on, but the algorithm is so simple that I don't see why we
can't just do it. More than one person commented that he got screwed
by either his program or the system placing too low a limit on the count,
because very long lists were involved.}
177: The second make-list example doesn't work, because the keyword is
missing. -- DLW [done]
177: (make-list) the note about the Lisp machine is false. I believe this is
the third time I have pointed this out. If you have an edition of the Lisp
machine manual whose cover is not gray or blue (i.e. red, or, God forbid,
black) throw it away. Gray and blue are the same except for who you get
it from. -- Moon [done]
178: copy-list should cross-reference copy-tree as well as copy-seq. -- Moon [done]
179: I'd rather not have the language definition mandate that nreconc
must be "more efficient". The wording here ought to say "except that
it is potentially more efficient". -- DLW [done]
179: The :test keyword is missing in the definition of pushnew. -- DLW
179: :test keyword missing from pushnew's heading line -- Moon [half done]
{will fix}
181: |P 1: 'copy the' -> 'copy of the' -- Moon [done]
182: (cross-reference to substitute) 'of sequence' -> 'of a sequence'
Also at the beginning of section 15.4 you should have a reference to
the sequence chapter, as in the beginning of 15.5, since it doesn't
say specifically under each function what :test means and what it defaults to. -- Moon [done]
* 182: does substitution only substitute for leaves (atoms), as the text
seems to say, or does it also substitute for conses, as in the Lisp machine
and Maclisp? -- Moon [done]
182: [gloss] subst is required to make a complete copy of the tree.
I'm not sure I'm happy about this, also nothing is said about whether sublis
makes a copy or not. --Moon
{On the contrary, the second sentence explicitly states that the
result of SUBST may share with the argument tree. Also,
examine the sample code for SUBST. Will clarify SUBLIS.}
185: [gloss] a-lists are specifically allowed to contain nil, and assoc
can't just take car of it, but must specifically ignore it and pass on.
This isn't really new, but was clarified.
{Will add implementation note that one can effectively
do the check outside the inner loop for speed.}
186: equal vs eql for assoc is noted twice -- Moon [done]
189: More S-expressions. This use, in particular, is vague, since the
exact meaning is important but the term S-expression was never defined.
I think the term "tree" is called for here. The same comment applies
to sxhash on p 191. Also, the examples use the puthash ex-function (RIP). [done]
189: puthash appears in examples. |P 4 thinks make-hash-table doesn't make all
kinds, but make-equal-hash-table has been flushed. The introductory sentence
of 16.1 has this problem, too. -- Moon [done]
190: The stuff about "bad luck" was lifted from the Lisp machine manual and applies
only to the particular weird implementation of EQ hash tables currently used there.
It doesn't belong in the Common Lisp manual. Just say "size is a hint to the
implementation how big a table to allocate initially." The default size should
be implementation-dependent, since the tradeoffs that determine what default is
appropriate are implementation-dependent. Under make-hash-table, say what
:test defaults to (presumably EQL). -- Moon [done]
192a: (Moon's proposal to clarify the meaning of "simple vector") [not done]
This proposal can be found in the file P:>common-lisp>simple-vector.proposal
{controversial}
192a: Flush the limitation of array dimensions, ranks, and index offsets
to fixnums. Just say that the limit is implementation-dependent and perhaps
add a note that in some implementations the limit coincides with the
fixnum/bignum boundary. Perhaps specify a minimum required value for the
limit on array dimensions, and specify that the limit on index offsets should
be the same as the limit on array dimensions. This affects pp. 11, 19 also. -- Moon
[not done]
{okay by me}
192b: Say explicitly what the default value of the :adjustable option is.
It looks from the surrounding discussion like it's NIL. -- DLW [done]
192b: The discussion of displaced arrays really is needed here. -- DLW [not done]
{will clarify}
192c: (at the bottom) The statement that make-simple-vector may be
easier for [sic] clearer to use it not well-justified; it looks to me
as if make-array is just as easy to use. Maybe you really mean that
it's good to use this function if you're trying to emphasize the fact
that the thing being produced is a simple vector? -- DLW [done]
* 192c: Is it make-vector or make-simple-vector? I prefer the former, because
it is shorter and because simplicity should be a secondary consideration. What
makes the vector simple is that you didn't use any of the "complex" keywords,
not specifically that it was created with make-vector rather than make-array. -- Moon
[gloss] make-vector uniformly renamed to make-simple-vector
192c: ':type' -> ':element-type' in examples -- Moon [done]
192d: array-element-type needs a cross-reference to subtypep. [done]
192d: array-dimension needs a cross-reference to length (esp. because of
fill-pointers). -- Moon [not done]
{will clarify}
192e: svref and sgvref should cross-reference to page 34 and give the type
expressions for the arguments they accept: (simple-vector * *) and
(simple-vector t *) respectively. -- Moon [done]
192e: Fractured English in the introductory paragraph of 17.4. -- Moon [done]
192f: |P 3, strike the sentence about indefinite number of arguments. -- Moon [done]
192g: fill-pointer itself seems to be missing. -- DLW
[gloss] It says that you use the LENGTH function to access the fill-pointer of an array.
* 192g: flush reset-fill-pointer, add fill-pointer, and allow setf of fill-pointer. -- Moon
[not done]
{controversial}
192h: ':type' -> ':element-type' in adjust-array -- Moon [done]
[not done] [i.e. it's only half done!]
{will fix}
192h: :type should be :element-type in adjust-array. Also, it should
probably say that the result is always :adjustable. Also, the phrase
"could have been created" is confusing; do we mean subtypep? Also, if
you use :fill-pointer t, presumably the fill pointer gets set to the new
array length, not the old one? --DLW [not done]
{will fix}
195: |P 3: 'optional' -> 'keyword'. |P 4: they aren't analogous "respectively"
because 'string-not-lessp' and 'string-not-greaterp' are out of order. I'd [done]
rather see these renamed to 'string-less-or-equalp' and 'string-greater-or-equalp',
not respectively. -- Moon [not done]
{will clarify}
195: There is a reference to STRING<> in the description of STRING-NOT-EQUAL,
which should be changed to STRING/=. --Benson [done]
* 195: string-trim should be specified to not necessarily make a copy, like
string-upcase. I guess it doesn't really make sense to give it :start/:end
arguments, though. -- Moon [done]
* 195: 'trim' is a good idea. Problem is that (TRIM bag seq) should trim from
both ends by default, so you have to use non-standard :FROM-LEFT and :FROM-RIGHT
keywords or something. And should the first argument be a bag or an element?
(If it's an element, you can get the bag effect with TRIM-IF and POSITION, but
that gets somewhat verbose). -- Moon
[gloss] the query was flushed
195: make-string needs a cross-reference to make-array for non-simple case. -- Moon [done]
197: if (string x) <=> (coerce x 'string) exactly, say so. Both of these
should coerce a character into a 1-element string; neither says so now. The
old argument against this, that people might expect string of a number to give
the decimal encoding of that number, no longer applies now that characters are
not numbers. -- Moon [done]
197: [gloss] string is required to signal an error if its argument is not a
string and not a symbol. This is wrong; it should convert a character to a
one-character string. Also it says that string will not convert a sequence of
characters into a string, but coerce will. This might be all right, except
under coerce it says that when coercing to a string the implementation is
allowed to return a more general type. It isn't clear if this is just a
poorly-phrased reference to the fact that make-array with an element-type
specified will return whatever array type is actually implemented that best
fits that element-type (in which case coerce to a string would return a string
since all implementations have strings), or whether this really is intended to
give the implementation freedom to do anything. Also the coerce writeup
doesn't say anything for or against coercing from a character to a 1-long string.
{controversial}
{will clarify}
* 203: I agree with Bawden's suggestion for revision of defstruct slot options -- Moon
[not done]
{okay by me}
204: |P 2: defstruct options are not in the same format as slot options -- Moon [not done]
{will fix}
* 204: How does defstruct create named vectors (second to last paragraph)
if neither make-array nor make-simple-vector takes a :named keyword? It would
be nice for defstruct to be written entirely in the portable language, not
in some magic implementation-dependent language. -- Moon [not done]
{controversial. Make a proposal? Is make-array the right place to
do this?}
205: constructors and predicates are specified as being in the same package
as the structure name. This is undesirable in the presence of package
inheritance. Specify that these names are interned in the package that is
the value of *package* when the defstruct macro is expanded. -- Moon [not done]
{will fix}
* 210: include applyhook as recently added to the Lisp machine. It's a third
argument to EVALHOOK, which is a function that gets called with the same arguments
as APPLY when EVAL is about to APPLY after evaluating arguments. This does not
intercept any other function calling in the interpreter, such as the one in
MAPCAR. The second argument to the applyhook is like an &rest argument in
extent (i.e. don't save it and also don't side-effect it). Either of the
two hook functions given to EVALHOOK may be NIL if you only need the other
one. Both hooks are disabled (bound to NIL) when either hook is invoked.
Longer explanation in the Release 4.0 release notes. -- Moon [not done]
{okay by me}
211: What does constantp do with a list whose car is QUOTE? -- DLW [done]
* 211: (constantp ''foo) -> t or nil? There are arguments in both directions. -- Moon [done]
[gloss] nil "because it does not evaluate to itself". This is, of course,
quite bogus since the symbol pi doesn't evaluate to itself either.
{Oooops. Chalk one up for muddy thinking. Okay, controversial.
I now favor (constantp ''foo) => T.}
* 212: When no values are returned, /, //, ///, *, **, and *** should not
be advanced, since nothing was printed. Likewise when execution is
aborted, they should not be advanced. Of course when printing is aborted
they should advance. Since these variables are for people, not for
programs, it is more important that * be the last thing that was printed
than that + and * be kept in sync. -- Moon [not done]
{controversial. I disagree -- parallelism is important, and I think that
/, //, /// should always advance.}
213: More S-expressions. -- DLW [done]
214: the with-open-stream special form of the Lisp machine is useful for
the same reasons as with-open-file. (with-open-stream (var maker) body...).
maker is a form that returns a stream; var is bound to it. -- Moon [not done]
{okay by me}
* 214: Add *debug-io*, for debugger interaction. It is rare, but not unknown,
for this to be different from *query-io*. -- Moon [done]
215: 'characters the substring' in make-string-input-string -- Moon [done]
216: the with-input-from-string example assumes that ? is alphabetic,
although it is reserved for the user, has the wrong value for j (it is
actually set to 11), and doesn't exhibit the common case where the :start
and :index keywords are the same (you have a variable containing the "current"
index into the string and you want it advanced). -- Moon [done]
[new] The text claims it exhibits the case where :start and :index are
the same, but it doesn't actually.
{will fix}
217: It's pretty strange that the "operations on streams" section does not
include input or output. I guess it is desirable to put the read-char
function near the read function, but you should either break up the huge
I/O chapter more or put in a cross-reference. -- Moon [done]
220: |P 2: closures are mentioned but have been flushed -- Moon [done]
220: (compatibility note) 'porvided' -- Moon [done]
220: |P 2: 'reader LISP' -- Moon [done]
221: |P 5: "dot context error" will not catch prinlength cutoff, since it
prints 3 dots. Or does it put spaces between them? -- Moon [not done]
{The new discussion of symbols in the data types chapter specified
that any token consisting entirely of periods is syntactically illegal
with the exception of a single-dot token in a place appropriate
for dot notation.}
* 221: where did IBASE go? -- Moon [not done]
{controversial}
221: using symbols as package names can't work; see my other comments. -- Moon
* 222: (table 21-1) # is a non-terminating macro character in the Lisp
machine now. If Common Lisp is going to have them, # should be one. -- Moon [not done]
{controversial}
223: (table 21-2) why are the upper and lower case exponent markers
not in the same order? Also right below this table there are spurious
references to table 22-3 (should be 21-3). -- Moon [done]
225: caseq used in an example -- Moon [done]
226: assq used in an example -- Moon [done]
228: the example of `#( calls make-simple-vector (which I think should
be called make-vector) with nil for the length. -- Moon [done]
230: (table 21-4) backspace appears twice, #: is undefined -- Moon [done]
231: The comment about #/ in the Lisp machine accepting both syntaxes is
false. -- Moon [done]
* 232: #. and #, have nothing whatever to do with quote. The way it's
written is confused and confusing (I admit it is probably my fault). You
mean to say "This allows you to include in an expression complex objects
that do not have a readable printed representation." -- Moon [done]
232: (under #,) 'unless unless the compiler' -- Moon [done]
232: 'too many bit are' -- Moon [done]
233: #nAform shouldn't use the word "form", since it's not a form at all
although you might think it would be. -- DLW [done]
233: '##' -> '#n#' since n isn't optional -- Moon [done]
233: The easiest way to make the ## example work is to change both
x's in the last line to y's. -- DLW [done]
* 233: (#=) It says the scope is "the outermost call to READ". Interaction
between recursive calls to READ is certainly mysterious. Probably there is
a kludge in BREAK to prevent the next READ from thinking it is called recursively.
I'd rather see a different function for macro-character functions that want
to read sub-expressions to call. This would unfortunately imply that
READ-DELIMITED-LIST is illegal for anything but a macro-character to call,
since it has to know which version of READ to use. If we don't add a separate
function, this mysteriosity should be carefully documented. -- Moon [not done]
{hard. I think a separate function will be needed. Alternatively,
how about an extra keyword :recursive to the input functions READ,
READ-PRESERVING-WHITESPACE, and READ-DELIMITED-LIST, which when
true specifies that a new ## scope is not to be made?}
233: is n optional in #nA ? -- Moon [done]
234: [gloss] #|...|# (as in ZL) added.
235: 'readtable' -> '*readtable*' in the example of restoring the readtable -- Moon [done]
235: In the copy-readtable example, the NIL isn't needed since that
argument is optional. -- DLW [done]
237: What do get-dispatch-macro-char and set-dispatch-macro-char do if the
disp-char is not actually a dispatch character? I will assume that they
signal an error, but that get- returns NIL if disp-char is a dispatch
char and sub-char is not defined. -DLW [not done]
{will clarify}
* 238: Can we find less barfucious names for the printer control variables?
The original motivation for these names, Maclisp compatibility for PRINLEVEL
and PRINLENGTH, went away when the stars were added. -- Moon [not done]
{controversial}
238: don't mix the variable descriptions into the middle of the text, it's [done]
extremely confusion, especially when the variable descriptions are incomplete
but appear before the text giving the real story. Move all the variable descriptions
to the beginning or the end, and make them complete or make them not break down
by data type at all. E.g. *prinescape* tells you about symbols but not strings. -- Moon
238: Another S-expression in *prinescape*, first line. -- DLW
{will fix}
238: There should be the equivalent of SI:PRINT-READABLY, which if true causes the
printer to signal an error rather than printing something that READ cannot
understand. (E.g. #<, prinlevel cutoff) -- Moon [not done]
{Another printer variable?}
239: (symbols) 'the only characters' -> 'only the characters' -- Moon [done]
* 239: Where did *ibase* go? -- DLW
{controversial}
240: Say explicitly what the default value of *princase* is. -- DLW [done]
240: (#:) there are some applications for which it is desirable to print
uninterned symbols as if they were interned -- provide a separate flag
to control the use of #:. [done]
240: (last line) 'close parenthesis "("' -- Moon
{will fix}
* 240: I think not allowing a package prefix before a vertical-barred symbol
is a dead loss. This affects page 226 (where vertical bar is described)
also. -- Moon
{controversial}
241: S-expression on first line. -- DLW
{will fix}
241: In the description of how to print arrays, I think you have left
and right confused. -- DLW
{No, I think it is correct. Examine it carefully.}
241: The DEFSTRUCT description refers to a :PRINT-FUNCTION option, while the
PRINT description refers to a :PRINTER option for DESTRUCT. The former
is correct. --Bawden,Benson [not done]
{will fix}
* 242: What is the defauly value of *prinarray*? -- DLW [done]
242: In the examples under *prinlevel*, the example where v=3 and n=2 is incorrect.
It says (if (member x items) ...). It should say (if (member x ...) ...). --DLW [not done]
{will fix}
* 243: nil and t as streams are silly. It's not as if the rest of the language
was Maclisp-compatible at this level of detail. -- Moon [done]
243: |P 3: 'see the end-of-file act according' -- Moon [done]
243: Making READ-PRESERVING-WHITESPACE a function rather than a special
variable you bind around a call to READ is nice. However, it brings
up the same problem with recursive calls to READ as #= does (my comment
about that, extracted from my general Laser-edition comments, is enclosed
for reference). Suppose you do (READ-PRESERVING-WHITESPACE)'FOO<space>;
that should preserve the space just as if there were no quote. But if
the quote macro character is defined the way it is in the example on
page 236, this won't happen; the inner call to READ will swallow the space.
If the quote macro character isn't really defined that way, and that is
just an oversimplified pedagogical example, then how are users supposed to
define their own macros? I think the old Maclisp "TYIMAN" family of crocks
are still with us.--Moon [not done]
{Regarding the proposal for a :recursive keyword to READ, perhaps
it would also when true cause the "global preserve-whitespace flag"
not to be altered.}
244: peek-char is used in an example with incorrect arguments -- Moon [done]
245: |P 2: (read-delimited-list) 'eof-value' -> 'eof-errorp' -- Moon [done]
245: The way read-line is expressed, it takes an input-stream. However,
the classic readline function echoes what it is doing and provides the user
with rubout handling. Similarly, read-char takes an input stream, but the
classic tyi function does echo. I think these functions should be defined
to do echoing on interactive streams; if not, we'll have to introduce
new ones that do. -- DLW [not done]
245: Does read-char echo on interactive streams? (Probably the answer
is "yes".) --DLW [not done]
{Sigh. Previously there was text to the effect that echoing is done
and people barfed at me. I think they were right at that time:
echoing is a property of the stream, or the interaction of the stream
and the function, not solely of the function.}
246: |P 6: 'involved, when clear-input' -> 'involved, then clear-input' -- Moon [done]
246: |P 3: peek-char should not say anything about echoing, since read
and read-char do not. -- Moon [done]
246: |P 5: 'these functions' -> 'read-char-no-hang' twice. -- Moon [done]
* 246: read-from-string cries out for &key arguments -- Moon [done]
* 247: parse-number cries out for &key arguments. Also returning 0 for a
null string is totally random. The Lisp machine function by that name
returns NIL in this case (assuming fail-if-not-whole-string is the same
argument as no-junk-allowed) -- Moon [done]
* 247: In parse-number, we should seriously consider changing the default
value of no-junk-allowed. -- DLW
It should be renamed to junk-allowed, and the default should still be NIL.
Thus the default should be to err if funny characters are seen. -- Moon
If you aren't receiving the second value, you shouldn't have to specify the
optional argument. If you are receiving the second value, you shouldn't
mind specifying the optional argument. Thus erring should be the default. [done]
-- MMcM (paraphrased by Moon)
248: print is defined to output a <return>, whereas terpri is
defined to do "whatever is appropriate", maybe a return-linefeed,
whatever. In other words, the spec is not clear about how to handle the
fact that some systems use CRLF and others use CR and other use LF. --DLW [not done]
{will clarify}
248: What does the write function return? -- DLW [done]
248: A minor point: PPRINT probably should not return its argument, in order
to be useful when called from a READ-EVAL-PRINT loop. Otherwise the
prettyprinted form tends to get scrolled off the screen by the
"standard" printed return value. This recommendation is made on the
basis of practical experience! Have it return T or NIL or some other
benign object instead. --Benson [not done]
{will fix. Similar argument as for APROPOS.}
249: What do write-string and write-line return? Similarly for the rest of
the output functions. It's fine with me if they are all defined to return
nil, but we should say explicitly. -- DLW [done]
249: the first example on p. 249 should say "princ", not "prin1". --DLW [not done]
{will fix}
251: A string with a fill-pointer is valuable as a format destination. -- Moon [done]
251: |P 1: 'arguments' or 'args' ? -- Moon [done]
252: Not having acquired my black belt in formatting, I didn't try
to verify the examples of format; somebody really ought to try
to run them in a Common Lisp or reasonable facsimile. -- DLW
252: nonexistent function 'control' used in an example -- Moon [done]
* 252: ~:A and ~:S should only affect the printing of NIL given directly
as an argument, not the printing of NILs inside a printed list. This is
because these are for printing an object that is known to be a list, not
for printing data so it can be read compatibly into a N.I.L system. -- Moon [not done]
{controversial}
253: (the query) No, I don't think it's what we want. -- DLW
254: (the query) Yes, I agree. The present formats are completely
random. Also ~$ is really nearly always what you want: this should
definitely be added. It's very important that you be able to control
exactly how many digits you get and how much space is occupied. -- DLW
254: [gloss] ~E and ~F deleted. But ~$ not put in.
254: (under ~&) 'a :fresh-line operation', but Common Lisp doesn't have
message-passing -- Moon [done]
254: random 'fi' in the second |P under ~C. -- Moon [done]
* 254: ~$ is highly useful and should be put in. Pending a concrete proposal,
I think Fortran ~E, ~F, ~G should be put in. I just looked at a Fortran
manual and they look reasonable, except that 1P should be the default scale
for E and G formats. ~$ is close to ~F but not identical, it would seem. I
doubt that anyone would mind changing "absolute goto" from ~G to ~@*. -- Moon
{controversial. I strongly urge the adoption of FORTRAN-like
floating-point formatting.}
* 255: (~T) There is an issue of what ~T should do if you are already in [not done]
exactly the column that is the goal. It could be defined to stay there,
or it could be defined to always output some whitespace. The Common Lisp
manual needs to say which. Here is how it is currently defined in the Lisp
machine, which was the result of some discussion. This is not in the manual. -- Moon
~m,nT n>0 always outputs at least one space
n=0 doesn't move if current position >= desired position
{okay by me}
256: (under '~(') '~;' -> '~' 3 times -- Moon [done]
256: [gloss] Third form of ~[, case-clause with explicit tags, has been removed.
257: ('~@[' example) 'prinlevel' -> '*prinlevel*', 'prinlength' -> '*prinlength*' -- Moon
{will fix}
258: funcall* used in an example -- Moon [done]
258: The phrasing of the "format-error" example was OK in the Lisp
Machine Manual, but in this manual one might wonder whether the
C.L. implementor is required to implement "format-error". You
could just rephrase to say "an implementor might happen to do the
following". -- DLW [not done]
{will clarify}
* 261: We recently changed the Lisp machine so that y-or-n-p always prints
"(Y or N)" after the message. I have no opinion about whether this is an
improvement. -- Moon [not done]
{controversial}
{okay by me}
261: The Lisp machine y-or-n-p types a (Y or N) after the prompt, and
yes-or-no-p types (Yes or No). This helps make the user interface more
uniform, and lets you know which kind of question you're being asked.
C.L. should work this way too. -- DLW [not done]
261: yes-or-no-p: The sentence "It is intended" doesn't come out right;
after all, it doesn't take much thought to type "yes <return>". I
know what you're trying to say but it needs to be rephrased. -- DLW [not done]
{will clarify}
265: type and version can be :unspecific on hosts like ITS, Unix, and Multics
that don't fit the pathname model exactly. The writeup on this in the Release
4.0 notes is good; remind us to send Steele a copy. -- Moon [not done]
{socket to me!}
266: truename of a stream should be a special case, returning the truename
of the file actually open, rather than first converting the stream to a pathname
and then taking truename of that (which can return a different answer). In
some implementations (e.g. ITS) truename of an output stream cannot return the
right answer until it is closed, because the version number isn't decided
until then. I don't have an answer for the query, except to provide some
data. In the Lisp machine, the PROBEF function returns NIL if the file does
not exist, but signals an error if there is an error accessing it, including
no such directory. On the other hand the :TRUENAME message currently returns
NIL for any FILE-OPERATION-FAILURE (this includes directory not found, access
violation, and the like, but not host down or not available). -- Moon [not done]
{will clarify}
267: parse-namestring cries out for keyword arguments. [not done]
{will fix}
Also change ':unspecific' to 'nil' in the paragraph about empty strings. -- Moon [done]
* 267: It looks like host names are followed by two colons. As far as I
can tell the text doesn't say anything about this; you only see it in the
examples. This is incompatible with Lisp Machine Lisp and is likely to
cause problems. On the other hand, it also fixes some problems. [Dave,
I think we have to talk about this.] -- DLW
[In the middle of page 266 it says that namestring syntax is implementation-dependent
and double colon for the host is used purely for purposes of examples. So
I don't think there is an issue. Of course, if logical pathnames are not
flushed then the namestring syntax cannot be implementation-dependent and
so there is an issue again. --Moon] [not done]
{controversial}
* 268: Rename merge-pathname-defaults to merge-pathnames and delete the
default-type argument (more :unspecific braindamage inherited from the Lisp
machine). Or keep it, but change the default value for the default-type to
the type of the defaults. -- Moon [not done]
{controversial}
268: Remove merge-pathname-default and replace it with merge-pathnames; see
the Release 4.0 Release Notes. The default-type argument is completely
wrong, although it took us long enough to find out. -- DLW
[I disagree with this; the thing that is wrong about the default-type
argument is not that it is there, but that it is -optional-. However
merge-pathnames is much more useful and Common Lisp might not bother with
merge-pathname-defaults. --Moon] [not done]
{controversial}
268: [gloss] default-type in merge-pathname-defaults defaults to NIL
instead of :UNSPECIFIC. Still wrong, it shouldn't be an optional
argument at all.
269: 'namelist' -> 'pathname' -- Moon [not done]
{will fix}
270: The merging rules should not include default-type, which turns out
to be completely wrong. Only default-version exists; types are defaulted
just in the obvious way. -- DLW [not done]
* 272: logical pathnames are totally useless if their namestrings aren't portable! -- Moon
[not done]
{controversial}
273: ':type' -> ':element-type' -- Moon [not done]
{will fix}
275: :overwrite should specify explicitly that it does NOT truncate the
file when the file is opened; if you want that, use :supersede. -- DLW [not done]
{will clarify}
275: :supersede's explanation says to supersede the file, which is
not very clear. It sounds like :new-version. The point is that
it is as if you make a new file with the same name as the old file,
and delete the old file when the new one is closed. -- DLW [not done]
{will clarify}
276: The "bindspec" in with-open-file's definition line is bogus. The
definition line should say (with-open-file (stream filename . options) {form}*.
As I keep saying, macros should have destructuring and functions should
not and attempting to introduce an analogy between these things is a mistake.
-- DLW [not done]
{will fix}
276: The error-p arguments to rename-file and delete-file probably come
from the Lisp Machine, where they are considered obsolete. They should
not exist for the same reason car doesn't have an error-p argument. -- DLW [not done]
{okay by me}
276: flush error-p argument to rename-file, etc. It is wrong. These functions
should signal their errors the same way as all other functions, and the same
mechanisms should be used to catch the errors when desired. -- Moon [not done]
{okay by me}
277: (file-length) 'position' -> 'length' -- Moon [not done]
{will fix}
279: For directory, specify that if a wildcard name is given and no
names match, it's not an error; directory returns the empty list. This
may seem obvious but based on our experience it deserves to be
documented. Also, if you give directory the name of a non-existent
file, it should return nil. As for non-existent directories, there has
been a running debate at Symbolics; one theory is that if you give it a
wilcard directory that doesn't match, return NIL, but if you give a
specific directory that does not exist, signal an error. You may not
want to go into this in full detail. Also, directory should not list
deleted files. We are going to have to upward-compatibly extend
directory by adding keyword arguments such as :deleted, so you may want
to put this into the definition in the first place and say that the
keywords are implementation dependent, although you might want to just
leave this open. -- DLW [not done]
{will clarify}
[Changes here not reviewed, assuming Moon's new proposal will be incorporated]
281: See general comments about the error system at the end of this file. -- DLW
282: I think condition-psetq is useless, although I could be wrong. Could
we leave this out until we have some evidence that it's good for anything? -- DLW
289: [gloss] BREAK added to chapter 24, I presume it will be flushed when
it is added to chapter 23 via Moon's new proposal.
{right}
289: First |P under compile: delete 'or select expression'
Second |P under compile: 'If name is a symbol' -> 'If name is a non-nil symbol' -- Moon
[not done]
{will clarify}
290: Second |P under compile-file: ':output' -> ':output-file' -- Moon [not done]
{will clarify}
291: Say explicitly in the second |P of require's description that the
pathname argument is optional if the module is semi-standard or in a
well-known place, and the way this works is implementation-dependent,
but the intention is that the system finds yellow-pages modules for you
without your having to know anything about pathnames. -- DLW [not done]
{will clarify}
* 294: apropos should return a list of the symbols found; this can be quite useful.
RMS recently changed his apropos to take arguments [not done]
string &key package superiors inferiors dont-print predicate
Common Lisp might want to adopt something like this, with perhaps keywords
to filter to only variables, only functions. -- Moon
{controversial. Keywords look okay. There is the same problem as with
PPRINT: after the nice-looking stuff has been printed, do you want your
screen garbaged up with the returned list?}
296: |P 2: dont say 'iff' -- Moon [not done]
{will fix}
297: (rationale) 'mnachine' -- Moon [not done]
{will fix}
* 298: host-software-type and host-software-version should not include the word
'host' in their names, since 'host' means something to do with networks. Perhaps
you want machine-hardware-type and machine-software-type, if 'machine' is the
substrate that supports 'lisp-implementation'. Also the documentation of
host-software-version accidentally documents lisp-implementation-version instead. -- Moon
[not done]
{will clarify}
* 298: In what package are the symbols that are elements of *features*? The
Lisp machine uses keywords currently, but compatibility is not an issue here
since the way you get to the list is different. -- Moon [not done]
{controversial}
--------
Major issues:
1. The rules for scoping of declarations need to be documented more clearly,
and may have real problems as well.
2. The package system contains fatal flaws. (See comments above)
3. The rules of numeric coercion need to be described explicitly. This
may not be a real issue once we know what they are. This relates to
Bawden's comments about Gaussian rationals as well. [not done]
4. What is the policy on dotted lists as sequences?
[gloss] The policy seems to be no policy, i.e. it says that the implementation
is allowed to choose whether or not to "behave reasonably"
{It "is an error" to use a dotted list as a sequence.}
5. The attempt to minimize the number of special forms is seriously flawed.
This is really part of the more general issue that many primitives are missing
from the language; thus many portions of Common Lisp that could otherwise be
written in a portable fashion cannot be, because primitives are missing. This
applies both to "modules" like defstruct, and to special forms as macros, when
there is nothing reasonable for them to expand into. The issue is not only
easing the work of implementation by permitting sharing of perhaps-inefficient
portable code, but also making it possible for users to customize things or
to experiment with language extensions without having to leave the Common Lisp
language. This is probably an issue for the longer term. [not done]
6. Examples are important in a manual, and their accuracy is important since
people will often read the examples and ignore the text. There should be
more examples, preferably an example of every case of every function, with
obvious redundancies removed (do not need to illustrate all possible
combinations of keywords for each sequence function!). Before the manual is
published as a real-world book, all examples should be tested (without being
retyped by a human being) if it is at all possible to find an implementation.
There should also be more cross-references between related features that
are in different chapters. [not done]
7. The error system is completely incompatible with ours. I would feel
bad if we had to move our new error system off to functions with
inferior names so that "signal" and "error" can refer to the Common Lisp
versions; in fact, implementing both error systems in the Lisp Machine
would be hard to do and might result in inefficiencies that we won't
want to have to put up with. This is a severe problem and I don't know
what we should do about it. -- DLW
I thought we agreed in August to prune the error system to just the functions
for signalling errors, and defer providing ways to handle errors (presumably
until the rest of the world agrees that the NES is the way to go, or until
there is enough experience with it to reveal what is really right.) I will
be upset if Common Lisp contains a kludge error system which we know from
experience is wrong and have just spent several months flushing from the
Lisp machine. As RMS has shown, the NES doesn't -really- require flavors,
although of course the second version of Common Lisp will include flavors.
Among the functions and special forms in chapter 23 only FERROR
(with no condition-name argument, a la NES), ASSERT, CHECK-TYPE would be
retained. FSIGNAL (from the Lisp machine) might be added as a minimal
mechanism for proceedable errors. The Maclisp-compatibility case of the
ERROR function might be added, although FERROR is probably always preferred
(in retrospect we should have ignored compatibility and used the name
ERROR for what is now FERROR). -- Moon
-------
∂25-May-83 0913 FAHLMAN@CMU-CS-C Finishing the Manual: Final Offer
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 25 May 83 09:13:19 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 25 May 83 12:13:16 EDT
Date: Wed, 25 May 1983 12:13 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: steele@CMU-CS-C
Cc: moon%scrc-tenex@mit-mc, dlw%scrc-tenex@mit-mc, declisp@CMU-CS-C,
vanroggen@CMU-CS-C, rpg@su-ai, fahlman@CMU-CS-C, newell@CMU-CS-A,
mcdermott@CMU-CS-A, raj.reddy@CMU-CS-A
Subject: Finishing the Manual: Final Offer
Guy,
As you know, I've been trying to reach you for a week and trying
intensively to reach you for the last three days. According to your
secretary at Tartan, you have not "been at your desk", you have not
returned my calls, and you have not answered any computer mail in
months. I am not willing to start calling you at home, bill-collector
style. If you don't want to communicate with me or with anyone else
about Common Lisp, I'm not going to try to force you.
It is now over a month since you said that you'd pull out all the stops
to finish the manual by the end of April, or as soon thereafter as
possible. It is over two weeks since Bill Wulf agreed to let you work
on the manual on company time. We are still in effectively the same
state we were in before this last "big push": total paralysis, induced by
the lack of a definitive manual and the lack of any effective way of
telling what is happening with the manual and which proposals are likely
to be accepted.
It is clear that you have done some editing, resulting in the May 10
shipment of files, but these address only about half of the issues
people have raised (see Moon's analysis in file
PRVA:<SLISP.SCL>LASER.UPDATE on CMUC). Despite my request to you at
Black Friday (May 13), we have not received any indication of which
parts of the manual are to be considered definitive, which of the
unanswered suggestions are oversights, which are still pending, and
which you have considered and rejected.
I don't believe that you realize how terribly disruptive and
demoralizing this state of affairs is to those of us trying to implement
this unspecified language. The continued delays and lack of
communication and status information are threatening the unity of the
Common Lisp effort, and they are doing terrible things to the schedules
of the DEC project, Spice Lisp, and the effort at Symbolics. The worst
effect is on morale -- I don't know about the rest of the participants,
but I am now very sorry indeed that I ever got involved in a joint
effort of this sort.
For my part, I have made a decision. The implementation efforts that I
am involved in are no longer interested in being a part of Common Lisp
as long as the final definition of Common Lisp is under your control, in
the sense that all decisions must wait for some action on your part
before they become final and documented. As of this moment, I am no
longer interested in hearing about your plans to finish the manual in
just a few more weeks or days or hours. I believe that I speak for the
DEC Vax effort in this, and I believe that the people at Symbolics feel
roughly the same way. It is now clear to all of us that it would be ten
times easier and a thousand times less stressful for someone else to
finish the manual than for us to try to get you to finish the manual.
And the manual must be finished, or dozens of man-years of effort and a
real opportunity to do something good goes down the drain.
I propose the following as a way to salvage something from this
unfortunate mess:
1. You turn the files now on CMUC, or any more recent versions that you
have hidden at Tartan, over to me. Working with Moon, Weinreb, and
Gabriel (if he wants to become actively involved in this), I will
attempt to resolve any outstanding issues via very quick arpanet
exchanges and then make the final edits.
2. I am willing to drop nearly everything else and to work day and night
on this until it is done.
3. My sole interest in this is to get the manual done, and to make sure
that the process of preparing subsequent editions does not stall as this
one has. Since the exisitng 90% of the manual is your work, I am
willing to leave you listed as sole author and to let you collect all
the royalties from publication, if that's the way you want it. (I
cannot speak for the others on this, however.) We will have to work out
some agreement on the copyright to ensure that a second edition will
appear a year from now, even if you do not participate.
4. I am not asking you to give up control completely. All changes would
be debated on the net, and I would treat any major objections from you
as being vetos. My high opinion of your taste as a language designer is
undiminished. However, if you do not respond on some issue, the rest of
us will feel free to resolve it without your input. We're going to be
moving very fast on this.
I would be willing to listen to other proposals that will accomplish the
same effect. Perhaps everyone would be more comfortable if Moon,
Weinreb, or Gabriel took over the effort instead of me.
Of course, since we decided to sign the copyright on the manual over to
you, you have the legal power to block this proposal, and to prevent
anyone else from building on the existing manual text. If you still
care at all about Common Lisp, you will not exercise this power.
I'm very sorry it has come to this. I wish that you had accepted one of
my earlier offers to help on this, or that you had somehow found the
time to do the job yourself, but we cannot change the past. I hope that
we can still salvage something.
-- Scott
∂25-May-83 1158 RPG Common Lisp Offer
To: RPG@SU-AI
Scott:
I am willing to put in a lot of effort to help finish the manual. I have
just now officially requested from the S-1 project a month of full-time
manual hacking, to start the end of next week. I am sure they will see
no problem with this.
In particular, I will help with all technical decisions, though I am
happy enough (as my silence is intended to imply) with the decisions
that have been made recently. I will help with the writing, and especially
the polishing, of any or all of the manual. If you would like to first-draft
sections of it, I will complete them for you.
I would be willing to travel to CMU in June for a week to help you in person,
if necessary.
I am puzzled by Steele's behavior (as you describe it) since, when I
talked to him a few weeks ago, everything seemed to be going fine. I hope
that nothing has happened to him or his immediate circle.
-rpg-
∂25-May-83 1228 FAHLMAN@CMU-CS-C Offer
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 25 May 83 12:28:03 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 25 May 83 15:29:03 EDT
Date: Wed, 25 May 1983 15:29 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Dick Gabriel <RPG@SU-AI>
Cc: Fahlman@CMU-CS-C
Subject: Offer
In-reply-to: Msg of 25 May 83 1202 PDT from Dick Gabriel <RPG at SU-AI>
Dick,
Your offer to help is greatly appreciated. Needless to say, taking over
the manual will rip about a month out of my summer that was already
pretty full, and sharing the load will help a lot. I think that there's
only about two weeks of actual work to do, including figuring out Guy's
funny Scribe macros and hassling with our Dover. Add to that a couple
more weeks to resolve all the last minute stuff.
I know that my message was strongly worded. What you heard was the
sound of the proverbial camel's back breaking.
I have been getting more and more ticked off about Guy's lack of
responsiveness for months, since even before the last-minute effort that
produced the Laser edition, with all its problems. I think that Guy is
OK, but that he has grossly overcommitted himself, feels guilty about
this, and is avoiding contact with me for the same reason I used to
avoid running into my thesis advisor. He's embarrassed. But his
response takes the form of freezing up and not of digging in and getting
this off his stack. I know that he believes he is on various critical
path things at Tartan (though Wulf was perfectly happy to have him work
on Common Lisp instead), and I know that Barb has been pressuring him to
work 9 to 5 and no more than that. So he's got all these conflicting
pressures and probably loathes the very mention of Common Lisp at this
point. Or that's my guess. I have offered several times to take the
whole mess off his hands. More than that I cannot do.
I imagine that Guy will think I'm over-reacting and that the obvious
thing to do is just to leave him alone to finish this at his own pace.
You understand why that is no longer an option, after 5 or 6 months of
broken promises and missed estimates, and with real comapnies paying
real money for these implementations.
When Wulf told him it was OK to hack Common Lisp on Tartan time, he
seemed to perk up for a day or two, and he got those new files over.
But since then it's back to the same old thing. I just haven't seen
him, and when I call, the secretary says he's in, then asks who is
calling, then discovers he's gone. She's not a very good liar.
I thought about starting to call him at home or to tell the secretary
that it was Ronald Reagan calling, but enough is enough. Hence my note.
You know him better than I do. Maybe you can find out what's happening
in his head. Id' be interested in any independent views of this.
-- Scott
∂25-May-83 1434 FAHLMAN@CMU-CS-C Offer
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 25 May 83 14:32:18 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 25 May 83 17:32:58 EDT
Date: Wed, 25 May 1983 17:32 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Dick Gabriel <RPG@SU-AI>
Subject: Offer
In-reply-to: Msg of 25 May 83 1202 PDT from Dick Gabriel <RPG at SU-AI>
Some additional data on Guy's state: a relaible source at Tartan tells me
that Guy has spent much of the last week putting the finishing touches
on the hacker's jargon file, which he is publishing somewhere. This
says something about his priorities, I think. He does seem to be in
reasonably good spirits overall and working on assorted things. When
asked by this person how the manual is coming, he says he doesn't want
to talk about it. The manual files appear not to have been touched
since May 10.
I would appreciate it if you didn't confront Guy with this info -- I'd
rather not have my source's cover blown. But it does make me feel like
I've done the right thing.
-- Scott
∂25-May-83 2118 FAHLMAN@CMU-CS-C Follow up
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 25 May 83 21:18:42 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 26 May 83 00:18:27 EDT
Date: Thu, 26 May 1983 00:18 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: moon%scrc-tenex@mit-mc, dlw%scrc-tenex@mit-mc, declisp@CMU-CS-C,
vanroggen@CMU-CS-C, rpg@su-ai, fahlman@CMU-CS-C, newell@CMU-CS-A,
mcdermott@CMU-CS-A, raj.reddy@CMU-CS-A, peter.hibbard@CMU-CS-A
Cc: Steele@CMU-CS-C
Subject: Follow up
I just got a call from Guy and we discussed how to proceed in light of
my message earlier today.
Guy made clear that he is still committed to the goals of the Common
Lisp effort. He also made clear that he would not use his copyright to
prevent the rest of us from finishing the manual, if that should become
necessary. However, he realizes now that he has not been giving the
manual a high enough priority, and he wants to work with the rest of us
to bring the manual to a successful completion as soon as possible.
Guy proposed the following division of labor: I will orchestrate the
debate on the remaining open issues and will attempt to gain a consensus
(or at least a decision) on each of them. On some of these issues, I will
be counting heavily on Gabriel, Wienreb, and Moon to help develop and
debug proposals. I will also take responsibility for final cleanup and
editing on the new Package and Error chapters.
In the meantime, Guy will finish up the editing on all those old issues
that require only editing. As new decisions are reached, Guy will edit
them into the manual. He will not attempt to play a major role in the
network debates, though of course he will express his opinion on those
issues he feels strongly about.
Over the next day or two, Guy and I will be developing a list of the
remaining controversial issues that have to be dealt with.
The key to all of this is that Guy and I have to keep our channels of
communication open, to each other and to the rest of the Common Lisp
community. Given that, I think this plan can work, and will get the job
done faster and better than if either of us tried to do the job alone.
At least, I am willing to give it one more try.
I will be sending a message to the Common Lisp mailing list soon,
to describe the new division of labor and to begin discussion of some of
the issues.
-- Scott
∂25-May-83 2125 Guy.Steele@CMU-CS-A Finishing the manual
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 25 May 83 21:25:05 PDT
Date: 26 May 1983 0017-EDT (Thursday)
From: Guy.Steele@CMU-CS-A
To: Scott.Fahlman <FAHLMAN@CMU-CS-C>, moon%scrc-tenex@MIT-MC,
dlw%scrc-tenex@MIT-MC, declisp@CMU-CS-C, vanroggen@CMU-CS-C,
rpg@SU-AI, Allen.Newell@CMU-CS-A, John.McDermott@CMU-CS-A,
raj.reddy@CMU-CS-A
Subject: Finishing the manual
First, of all, I would like to offer my abject apologies for my lack
of communication. I have a bug that I much prefer to present polished
work fully done than to dribble out partial drafts. Also, given the
choice between processing mail and answering it when there is not time
for both, I tend to give higher priority to processing it. I feel very
badly that this has given you all the feeling of hanging.
>From my viewpoint I don't think the situation is as bad as it probably
seems from yours. My predictions of a month ago went badly awry. Let me
raise one point in defense and then let it drop: the volume of mail,
measured in pages, of the Common LISP discussion for the last month
(mid-April to now) has exceeded in volume the mail for the entire six
months before that (mid-October to mid-April, that is, since before the
Laser edition).
Here is a proposal for action (I have already discussed this with Scott).
I would like to ask Scott to undertake the task of preparing the ERROR
and PACKAGE chapters according to the discussions of the last month.
(Besides technical problems, much of the work is simply preparing it
properly for SCRIBE. There are dozens of magic macros.) In addition,
I would like to transfer to him the task of coordinating quick resolution
of outstanding trivial problems. I will continue to track mail
on trivial problems. Additionally, I am going into super burnout mode
betwen now and Tuesday to get completely caught up on all old issues,
that is, all comments and discussion as of mid-April. I will also
work on the problem of an improved index. After that point, we will see
what is the best strategy to pursue on resolving any remaining issues.
By the afternoon of Thursday, May 26, I hope to have completely gone over
Moon's list of outstanding problems and send to you all a note on my
perception of the status of each.
I do not want the Common LISP effort to fall apart. To answer Scott's
apprehensions, I state firmly that while there is a copyright notice in
my name on the text, this was, as previously agreed, purely for the purpose
of maintaining control of the document in the hands of the Common LISP
group rather than letting it pass de facto into the hands of any one
subgroup. The work was supported by university funding and it would be
wholly unethical for me or for anyone to block use of the text for selfish
reasons. If it becomes apparent that the Common LISP effort is best
served by my passing "control" of the manual into other hands, then I will
do so. This will almost certainly happen eventually, but I do not believe
that the time is now. I suggest that the situation be re-evaluated in
one week's time.
--Guy
∂26-May-83 0753 FAHLMAN@CMU-CS-C Manual update
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 26 May 83 07:53:00 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 26 May 83 09:55:06 EDT
Date: Thu, 26 May 1983 09:55 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: common-lisp@su-ai
Subject: Manual update
For reasons too complicated to discuss here, progress on the Common Lisp
Manual has been rather slow lately. Guy and I have discussed how to fix
this, and we have decided that the best way to converge quickly is for
him to concentrate on editing in the relatively non-controversial things
and those items on which decisions have been reached, and for me to
orchestrate the arpanet-intensive process of reaching some sort of
consensus (or at least a decision) on those issues that still require
some debate. I will keep some sort of file on the decisions that have
been reached to date -- more on this in a later message. Guy will be
watching these debates and commenting where appropriate, but will not be
doing the day-to-day message answering.
Given the need to move fast on this, I do not propose to do this via a
single moby ballot. Instead, I will raise issues one by one or in small
groups, and will in most cases attach a strong recommendation or
proposal to each. People will have 48 hours or so to object or raise
counter proposals -- longer, of course, for the more complex issues.
Then a decision will be announced, will be put in some sort of file, and
will be turned over to Guy for inclusion in the manual. Implementors
should feel fairly safe in treating the things in this file as settled.
It will be possible to re-open issues after the gavel has come down, or
for that matter to re-open any old wounds, but the threshold for getting
a change adopted or even a fair hearing will be very much higher in such
cases. At that point, mere tastefulness (or lack thereof) will probably
not suffice -- only arguments of the form "The language cannot possibly
work if we retain X" or "X is unimplementable" or "X will be devastating
to potential users of Common Lisp" will be entertained at that point.
I will endeavor to strike a reasonable balance between speed and
decisiveness, on the one hand, and giving everyone a fair hearing, on
the other. If anyone thinks I'm drifting too far in either direction,
apply feedback.
Does anyone object violently to this new scheme? If so, speak now, but
be sure to include a viable counter-proposal.
-- Scott
∂26-May-83 1029 JMB@S1-A Common Lisp Calls!
Received: from S1-A by SU-AI with TCP/SMTP; 26 May 83 10:29:10 PDT
Date: 26 May 83 1024 PDT
From: Jeff Broughton <JMB@S1-A>
Subject: Common Lisp Calls!
To: rpg@SU-AI
∂25-May-83 1128 RPG@SU-AI Common Lisp Calls!
Received: from SU-AI by S1-A with TCP/SMTP; 25 May 83 11:28:38 PDT
Date: 25 May 83 1130 PDT
From: Dick Gabriel <RPG@SU-AI>
Subject: Common Lisp Calls!
To: jmb@S1-A
I am sending under separate cover a note from Fahlman to several of us
principals in the Common Lisp Group, discussing Steele and the manual.
I would like to throw my energies into the manual-completing project.
I plan to work starting friday until saturday, week, with Rod on the compiler
and GC code. I'd like to spend up to a month on the manual with Fahlman and
Moon. My question is: will you (and Tom?) approve of this activity as
project related? I hope so, since Common Lisp may be sunk unless something is
done.
-rpg-
[Seems project related to me. -jmb]
∂26-May-83 1151 JMB@S1-A Common Lisp Manual
Received: from S1-A by SU-AI with TCP/SMTP; 26 May 83 11:51:09 PDT
Date: 26 May 83 1046 PDT
From: Jeff Broughton <JMB@S1-A>
Subject: Common Lisp Manual
To: rpg@SU-AI
I a more than a little bit concerned about the discussion of the copyright
on the Common Lisp manual, particularly the parts about control and royalities
for publication.
Since this work was partially supported with government funds, there can be no
personal, corporate or other copyrights associated with it. PERIOD. All
participants, particularly Steele, should be aware that if any attempt is
made to profit from its publication or to restrict its release, appropriate
injunctions or damages will be sought.
I could get still more excited about this, but I will let you reassure me
that things are not as bad as they seem.
-jmb
∂27-May-83 0623 FAHLMAN@CMU-CS-C Comments on LASER.UPDATE
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 27 May 83 06:22:33 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 27 May 83 09:23:12 EDT
Date: Fri, 27 May 1983 09:23 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: STEELE@CMU-CS-C
Cc: declisp@CMU-CS-C, dlw%scrc-tenex@MIT-MC, guy.steele@CMU-CS-A,
moon%scrc-tenex@MIT-MC, rpg@SU-AI, vanroggen@CMU-CS-C
Subject: Comments on LASER.UPDATE
In-reply-to: Msg of 27 May 83 01:23:14 EDT from STEELE
Guy,
Thanks for getting this pass done. I will use this this list (and some
other things in the mail file) to generate a series of mini-ballots and
proposals, and see if we can wrap up these decisions as quickly as
possible.
If any of the rest of you on this list, acting as a sort of "executive
committee", want to flag certain additional things as controversial or
come in early with opinions on some of them, feel free. When I do send
these out to Common Lisp, I will be making a strong recommendation on
each, and on some of them I will be checking with some or all of you to
get advice on what that recommendation should be.
-- Scott
∂29-May-83 1122 GJC@MIT-MC
Received: from MIT-MC by SU-AI with TCP/SMTP; 29 May 83 11:22:46 PDT
Date: 29 May 1983 14:07 EDT
From: George J. Carrette <GJC @ MIT-MC>
To: COMMON-LISP @ SU-AI
Does anybody have a LIST (i.e. a file with "(CAR CDR CONS ...)" in it)
of all common-lisp defined functions and variables in it?
(Perhaps some code to parse the SCRIBE source of the manual?)
∂30-May-83 0020 RPG [Moon%SCRC-TENEX: New setf writeup]
∂27-May-83 2218 FAHLMAN@CMU-CS-C [Moon%SCRC-TENEX: New setf writeup]
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 27 May 83 22:15:45 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 28 May 83 01:16:50 EDT
Date: Sat, 28 May 1983 01:16 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: rpg@su-ai
Subject: [Moon%SCRC-TENEX: New setf writeup]
Just sent this to Guy, meant to CC you too...
Guy,
I asked Moon to write up his hairy DEFSETF proposal in manual-insertion
format. He has done so and the result is on <fahlman.clm>defsetf.mss.
This writeup looks good to me -- it's hairy, but doing DEFSETF right has
to be hairy. The substance of this proposal has kicked around the
Common Lisp circuit several times, so it take it to be "approved"
already -- I even sent out a last call for quibbles awhile back.
The one new item is the elimination (for now at least) of the provision
for the new-value argument to take a lambdalist to handle multiples.
This too went around the list. That second lambda-list was your baby,
so if you don't object to its elimination, then I'm sure that nobody
else does. We are retaining the (x) syntax so that we can make this a
full lambda list later, if we ever find some good reason to.
This file may not be in totally legal Steelese Scribe. Probably the
quickest thing is for you to make a pass over it and then stick it in if
you don't spot anything bogus. If you want someone to proof it through
Scribe before it goes in, I'll ask Monica to, but that will add a couple
of days since her stack is already full.
I had hoped that by tonight I could get back to you on all the "OK by
me" issues you flagged, either to tell you that all of these are also OK
by me or perhaps to take exception to one or two of them. This will
have to wait till sometime tomorrow, probably in the evening. I lost
almost a whole evening tonight -- went to the airport to pick up Penny's
brother and his wife and U.S.Error kept us hanging around for 3 1/2
extra hours! I didn't think to take any work along.
I'm not sure what sort of confirmation you want on these "OK by me"
issues. Obviously thse are OK by Moon & Co. and by you. I'll sign off on
almost all of them tomorrow, and maybe you should ask RPG to do so as
well. I think that with that much confirmation, it's OK to put these in
the manual. In going through them, I'll try to flag any that are so
controversial they might need a vote, even if I agree with them.
Once we're clear on those items, I'll start sending out messages on the
controversial ones -- those on Moon's list and those raised in some
of the other recent messages.
There's one item that really has to be dealt with by you: Benson's very
recent message on separating the names of functions from the functions
themselves, with lambda expressions being the former. This looks
somewhat dubious to me, and has drawn an objection from Bawden. This is
clearly an issue on which you are the best qualified to speak, one way
or the other, since Benson's suggestion was inspired by the "Art of the
interpreter" paper. This doesn't have to be handled before you finish
the current editing pass, but the issue probably won't go away till you
comment on it.
-- Scott
∂30-May-83 0020 RPG Issues raised by MOON and DLW
∂28-May-83 1150 FAHLMAN@CMU-CS-C Issues raised by MOON and DLW
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 28 May 83 11:49:57 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 28 May 83 14:51:06 EDT
Date: Sat, 28 May 1983 14:51 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: steele@CMU-CS-C
Cc: moon%scrc-tenex@mit-mc, dlw%scrc-tenex@mit-mc, rpg@su-ai,
fahlman@CMU-CS-C
Subject: Issues raised by MOON and DLW
Guy,
I have now read over your response to the shopping list from Symbolics,
and all of the things that you list as "OK by me" are also OK by me,
with the following exceptions and comments:
41: I would really like COND to be the special form in here, and maybe
also AND and OR, with IF as the macro. Tradition, and that's the way we
have it implemented. I suppose that program-understanding programs
would be happier with IF, but hairy COND forms become pretty awful when
expanded into IF.
42: I agree with the idea to allow implementation-dependent functions
but not special forms in macro-expansions. At least, I'e been unable to
come up with an example where this screws us. HOWEVER, we'd better run
this by the crtics gallery, to make sure we're not missing anything
important, so I would keep this one as "controversial".
49: On DEFCONSTANT, go ahead and flush the error, but I object fairly
strongly to the := suggestion. It's a flaw that we don't have any good
way to leave a documented DEFVAR unbound, but I've never needed this in
practice.
80: The proposal to change LOOP to make a BLOCK NIL around the tagbody
has already passed by Common Lisp with no objection, and it is clearly
necessary. I would take this as being approved.
101: The proposal to make global DECLARE into PROCLAIM, thus solving the
ambiguity problem for SPECIAL, has already flown and is in fact already
implemented in my new lexical interpreter. But let's call this
controversial and let me run it by the masses one more time, since I'm
not sure everyone publically agreed that it was resolved.
168: BSG's proposal to flush MAXPREFIX and MAXSUFFIX and to change the
counting on MISMATCH :FROM-END were unopposed and look very good to me.
I'd treat this as adopted.
203: I'll have to go look up Bawden's proposal on DEFSTRUCT slot
options, but if this is the one where he proposes an :INIT keyword, that
is fine with me. But not if it's named := .
210: I think I've got a problem with APPLYHOOK. This should be
considered controversial and should not go in yet. Could MOON or DLW
send out a definite proposal instead of indirecting through the 4.0
release notes? In any event, I am opposed to having CLM specify this
business about the volatility of &rest args -- I would hope that
Symbolics plans to fix this someday. (Only "cheat" in compiled code,
and have the compiler tell if such cheating is OK for a given function,
or something like that.)
211: It seems to me that the reason we're ahving trouble with Constantp
is because it's a confused and relatively useless function that ought to
be punted. There are a number of behaviors that you might want from
such a function, depending on what it's for, and any of those behaviors
is easibly obtainable by a user-written function.
233: I am enthusiastic about the :RECURSIVE keyword to the READ family.
However, I would change it to :CALLED-RECURSIVELY or :INTERNAL-CALL or
something.
241: I think that the source of the confusion here is the use of the
terms "left-parenthesis" and "right-parenthesis". I can't ever remember
(and I'm not sure if there is a global authority on this) whether the
left paren is the one that is on the left of a list, or whether it's the
one that points to the left. How about "open-paren" and "close-paren"?
245: I agree with Guy that echoing should be done here, regardless of
who may have barfed earlier. (One free barf-bag and a ticket to Monty
Python's Meaning of Life if that person repeats the act.)
254: Sounds like we all favor Fortran-like ~E, ~F, and ~G floating-point
and/or some form of ~$. All we need now is a concrete proposal.
Anything halfway reasonable would be an improvement. Any volunteers?
RPG, maybe?
261: The exact form of the Y or N query should be left to the
implementation, but some wording indicating that the user should not
include "(Y or N)" because the system will supply some appropriate
prompt would be good.
267: Looks like there are N controversial points surrounding the file
system business. I'd like to see a new concrete proposal from someone.
Volunteers? Symbolics may have the strongest opinions here, so maybe
they should try to produce a specific proposal, if they can keep it
simple.
My one personal gripe about this, which I've raised N times, is
that the concepts of HOST and NAMING-PROTOCOL should not be
muddled, but should be separate slots. A host is like "CMUC" or
"CMU-CS-WOMBAT" while a naming protocol is like "Tops-20" or "unix" or
"Spice-CFS". You can maybe determine the naming protocol from the host
name in an implementation-specific or site-specific way, but that's no
reason to smash the two together. It is the naming protocol that the
parsing function needs to know.
All "controversial" issues not mentioned here will either result in a
proposal before the Common Lisp mailing list or in a private attempt on
my part (cc at least to all of you) to get the proposer to reconsider
whether the change in question is a good idea.
-- Scott
∂30-May-83 0021 RPG Ok-by-me's
∂28-May-83 1314 FAHLMAN@CMU-CS-C Ok-by-me's
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 28 May 83 13:14:09 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 28 May 83 16:14:45 EDT
Date: Sat, 28 May 1983 16:14 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Dick Gabriel <RPG@SU-AI>
Cc: GLS@SU-AI
Subject: Ok-by-me's
In-reply-to: Msg of 28 May 83 1308 PDT from Dick Gabriel <RPG at SU-AI>
Dick,
Looks like Guy is eager to do the ~F,~G,~E,~$ proposal, so my suggestion
that you should think about this is inoperative.
-- Scott
∂30-May-83 0021 RPG Issues raised by MOON and DLW
∂28-May-83 1446 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN Issues raised by MOON and DLW
Received: from MIT-MC by SU-AI with TCP/SMTP; 28 May 83 14:27:40 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Sat 28-May-83 17:30:52-EDT
Date: Saturday, 28 May 1983, 17:22-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Issues raised by MOON and DLW
To: Scott E. Fahlman <Fahlman%CMU-CS-C@SU-DSN>
Cc: steele%CMU-CS-C@SU-DSN, moon%SCRC-TENEX%MIT-MC@SU-DSN,
dlw%SCRC-TENEX%MIT-MC@SU-DSN, rpg@su-ai
In-reply-to: The message of 28 May 83 14:51-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
This message will be a bit longer than necessary, since I'm not going to
delete any of Scott's message from it, for archival purposes.
Date: Sat, 28 May 1983 14:51 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
Guy,
I have now read over your response to the shopping list from Symbolics,
and all of the things that you list as "OK by me" are also OK by me,
I haven't seen this list. Should I?
with the following exceptions and comments:
41: I would really like COND to be the special form in here, and maybe
also AND and OR, with IF as the macro. Tradition, and that's the way we
have it implemented. I suppose that program-understanding programs
would be happier with IF, but hairy COND forms become pretty awful when
expanded into IF.
See second paragraph below.
42: I agree with the idea to allow implementation-dependent functions
but not special forms in macro-expansions. At least, I'e been unable to
come up with an example where this screws us. HOWEVER, we'd better run
this by the crtics gallery, to make sure we're not missing anything
important, so I would keep this one as "controversial".
We have large numbers of macros that expand into
implementation-dependent special forms. This is unavoidable. Is this
restriction intended to apply to all macros, or only to macros that are
documented in the Common Lisp manual? If the latter, I'd have to check
carefully, but it is perhaps possible that none of them need to expand
into implementation-dependent special forms.
I really believe that the attempt to limit the number of special forms
is inherently unworkable. I do have a "template" scheme, partly
borrowed from Interlisp Masterscope, that makes it possible for a
portable program to "understand" certain limited kinds of
implementation-dependent special forms (basically ones that don't change
the flow of control in "strange" ways). It can handle most forms of
binding, setting, and evaluation of subforms. SETF and related tools
are based on this.
49: On DEFCONSTANT, go ahead and flush the error, but I object fairly
strongly to the := suggestion. It's a flaw that we don't have any good
way to leave a documented DEFVAR unbound, but I've never needed this in
practice.
I guess I need to see the proposed change. We get around the problem with
unbound documented defvars by never documenting any variables, except with
comments, which isn't really very good.
80: The proposal to change LOOP to make a BLOCK NIL around the tagbody
has already passed by Common Lisp with no objection, and it is clearly
necessary. I would take this as being approved.
Yes.
101: The proposal to make global DECLARE into PROCLAIM, thus solving the
ambiguity problem for SPECIAL, has already flown and is in fact already
implemented in my new lexical interpreter. But let's call this
controversial and let me run it by the masses one more time, since I'm
not sure everyone publically agreed that it was resolved.
Sure.
168: BSG's proposal to flush MAXPREFIX and MAXSUFFIX and to change the
counting on MISMATCH :FROM-END were unopposed and look very good to me.
I'd treat this as adopted.
Yes. Unless there are new rationales for them that I haven't heard.
203: I'll have to go look up Bawden's proposal on DEFSTRUCT slot
options, but if this is the one where he proposes an :INIT keyword, that
is fine with me. But not if it's named := .
I don't remember.
210: I think I've got a problem with APPLYHOOK. This should be
considered controversial and should not go in yet. Could MOON or DLW
send out a definite proposal instead of indirecting through the 4.0
release notes?
I'll send something under separate cover, after I go look at the code.
But it's really very simple.
In any event, I am opposed to having CLM specify this
business about the volatility of &rest args -- I would hope that
Symbolics plans to fix this someday. (Only "cheat" in compiled code,
and have the compiler tell if such cheating is OK for a given function,
or something like that.)
We have very long-term plans to fix this, but it isn't easy and we can't
promise any sort of schedule. Furthermore the plan is based on
exploiting some special hardware we have in the machine, which suggests that
other implementations will find this problem considerably harder to
solve. What do your implementations do?
It is essentially impossible to do it at compile time, because many
&rest arguments are passed as arguments to functions which in fact will
only use them in a "downward" way, but the compiler doesn't know that.
The efficiency cost of being conservative there would be too high, at
least in our implementation where the ratio of the cost of CONS to the
cost of CDR is very high. This is certainly a wart, but I'm not sure
what to do about it. Possibly a declaration or two ways of spelling
&REST.
211: It seems to me that the reason we're ahving trouble with Constantp
is because it's a confused and relatively useless function that ought to
be punted. There are a number of behaviors that you might want from
such a function, depending on what it's for, and any of those behaviors
is easibly obtainable by a user-written function.
Not so! The way you tell whether a symbol has been declared as a constant
with DEFCONSTANT is implementation-dependent. Furthermore the set of
self-evaluating data types is implementation-dependent, because of extensions
to the standard language. I don't think the function is useless, certainly
not in the kind of program-manipulation code I've been writing recently.
The confusion I think derives from one thing: does this function operate
on forms or on objects? It seems clear from its presence in the eval
chapter that it should operate on forms, which means that it should be true
of lists whose car is QUOTE. But its English description isn't written that
way. This seems resolvable.
Incidentally I also found a need for a function called VARIABLEP. This is
not (NOT (CONSTANTP ...)), rather it is true for "things you can bind", which
as it happens is equivalent to (AND (SYMBOLP X) (NOT (CONSTANTP X))). But
the function may be worth having separately anyway. Not a big deal, since
we will have it internally anyway, but I thought I'd mention it in case it
seems appropriate to make it standardly available.
233: I am enthusiastic about the :RECURSIVE keyword to the READ family.
However, I would change it to :CALLED-RECURSIVELY or :INTERNAL-CALL or
something.
I'd have to see the proposal.
241: I think that the source of the confusion here is the use of the
terms "left-parenthesis" and "right-parenthesis". I can't ever remember
(and I'm not sure if there is a global authority on this) whether the
left paren is the one that is on the left of a list, or whether it's the
one that points to the left. How about "open-paren" and "close-paren"?
I've never heard of this confusion before. ( is a left parenthesis and
) is a right parenthesis. I would hesitate to guess which way either of
those is said to "point". There is one place on page 241 where "left"
and "right" are interchanged. Is there more confusion there than just
that typographical error? Since every place else in the manual I
can see says "open" and "close", I guess this terminology should be used
consistently and "left" and "right" should be removed.
245: I agree with Guy that echoing should be done here, regardless of
who may have barfed earlier. (One free barf-bag and a ticket to Monty
Python's Meaning of Life if that person repeats the act.)
This is about read-char? I agree that the "simple" functions should take
care of echoing, input editing, wakeup control, and so forth in whatever
implementation-dependent way is appropriate (and this is -damned- implementation
dependent!) For now, screen editors will have to read their commands in
an implementation-dependent way. We might consider standardization of
more detailed interactive I/O (both keyboard and screen) for the second
edition.
254: Sounds like we all favor Fortran-like ~E, ~F, and ~G floating-point
and/or some form of ~$. All we need now is a concrete proposal.
Anything halfway reasonable would be an improvement. Any volunteers?
RPG, maybe?
Yes. I don't volunteer to write the proposal though. I think I've already
mailed out the documentation on the present Lisp machine/Maclisp/NIL ~$
(it's too recent to be in the Chine Nual) and I could mail it out again
if you want. The present Lisp machine FORMAT has nothing of worth to
offer for ~E,~F,~G.
261: The exact form of the Y or N query should be left to the
implementation, but some wording indicating that the user should not
include "(Y or N)" because the system will supply some appropriate
prompt would be good.
Good.
267: Looks like there are N controversial points surrounding the file
system business.
Does this refer to everything in chapter 22 or just pathnames?
I'd like to see a new concrete proposal from someone.
Volunteers? Symbolics may have the strongest opinions here, so maybe
they should try to produce a specific proposal, if they can keep it
simple.
Maybe Dan can do this, he'll have to say, but I don't think I can find the
time and energy to deal with this right now, with all the other things
I'm trying to stay on top of.
My one personal gripe about this, which I've raised N times, is
that the concepts of HOST and NAMING-PROTOCOL should not be
muddled, but should be separate slots. A host is like "CMUC" or
"CMU-CS-WOMBAT" while a naming protocol is like "Tops-20" or "unix" or
"Spice-CFS". You can maybe determine the naming protocol from the host
name in an implementation-specific or site-specific way, but that's no
reason to smash the two together. It is the naming protocol that the
parsing function needs to know.
All "controversial" issues not mentioned here will either result in a
proposal before the Common Lisp mailing list or in a private attempt on
my part (cc at least to all of you) to get the proposer to reconsider
whether the change in question is a good idea.
-- Scott
∂30-May-83 0021 RPG Changes to Laser edition for APPLYHOOK
∂28-May-83 1513 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN Changes to Laser edition for APPLYHOOK
Received: from MIT-MC by SU-AI with TCP/SMTP; 28 May 83 15:12:04 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Sat 28-May-83 18:12:41-EDT
Date: Saturday, 28 May 1983, 18:04-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Changes to Laser edition for APPLYHOOK
To: Fahlman%CMU-CS-C@SU-DSN
Cc: Steele%CMU-CS-C@SU-DSN, RPG@SU-AI, Moon%SCRC-TENEX%MIT-MC@SU-DSN,
DLW%SCRC-TENEX%MIT-MC@SU-DSN
Rationale:
When stepping through an interpreted program, it is desirable to be able
to pause before each evaluation, to pause after each evaluation so that
the value can be examined or changed. These operations can be done with
the evalhook feature. It is also desirable to pause before invoking
a function (whether a user function or a system function), so that the
values of the arguments may be examined or modified. This requires the
applyhook feature, or else requires duplicating an unnecessarily large
part of the EVAL function.
The applyhook feature catches only APPLY operations done by EVAL. It
does not catch APPLY done in other parts of the interpreter (i.e. by
special forms: CATCH-ALL and UNWIND-ALL are the only ones in Table 5-1
that would do an APPLY), nor does it catch APPLY or FUNCALL operations
done by functions (MAPCAR for instance). Stepping through APPLY
operations done by a function such as MAPCAR are best done by
intercepting the call to MAPCAR, using the apply hook, and substituting
a different first argument.
Note:
The writeups for APPLYHOOK and *APPLYHOOK* should be largely copied
from the writeups for EVALHOOK and *EVALHOOK*. I have not made any
attempt to do this, but have just indicated the differences.
New variable *APPLYHOOK*: (analogous to *EVALHOOK*)
When non-NIL, EVAL behaves in a special way. Whenever it is about to
apply a function to the values of the function's arguments, which have
already been evaluated, instead it calls the value of *APPLYHOOK* with
two arguments: the function and its list of arguments. Whatever values
the hook function returns are taken as the results.
The list of arguments is just like an &rest argument in its volatility.
If the hook function just calls APPLY on its first two arguments, EVAL
would behave in its normal way except a little slower. [Of course the
preceding sentence isn't true in a lexical interpreter, where the
internal environment-taking APPLY isn't accessible to the user except
through the APPLYHOOK function, below.]
[The apply hook function gets additional "env" arguments just like the
eval hook function.]
EVAL binds both *EVALHOOK* and *APPLYHOOK* to NIL around calls to either of them.
EVALHOOK takes an extra argument:
*APPLYHOOK* is bound to the third argument (before the "&rest env"), a function
or NIL.
New function APPLYHOOK: (analogous to EVALHOOK)
The arguments are function, arglist, evalhook, applyhook (&rest env).
This function is completely analogous to EVALHOOK and is to be called by
*APPLYHOOK* functions in the same way that EVALHOOK is to be called by
*EVALHOOK* functions, to "jump back into the interpreter".
Macros and special forms:
*APPLYHOOK* does not affect the invocation of a macro expansion function.
Currently in the Lisp machine *APPLYHOOK* affects special forms; the function
and argument list passed to the hook function are such that using APPLY on
them will do the right thing. SPECIAL-FORM-P will be true of the function.
The argument-list is usually just the cdr of the form being evaluated, but
this isn't guaranteed and depends on the particular special form. Exceptions:
special forms that are really implemented as macros are not affected by
*APPLYHOOK*, nor is the QUOTE special form.
I am amenable either to leaving this the way it is or to saying that
*APPLYHOOK* has no effect on special forms. Since the Lisp machine allows
"functions with "e arguments" we will probably have *APPLYHOOK*
still affect them, however they would not appear in any Common Lisp programs,
and I think we can arrange for it not to affect "real special forms."
∂30-May-83 0021 RPG Issues raised by MOON and DLW
∂28-May-83 1548 FAHLMAN@CMU-CS-C Issues raised by MOON and DLW
Received: from SU-DSN by SU-AI with PUP; 28-May-83 15:48 PDT
Received: From CMU-CS-C by SU-DSN.ARPA; Sat May 28 15:10:46 1983
Received: ID <FAHLMAN@CMU-CS-C>; 28 May 83 18:09:15 EDT
Date: Sat, 28 May 1983 18:09 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: David A. Moon <Moon%SCRC-TENEX@MIT-MC>
Cc: dlw%SCRC-TENEX@MIT-MC, rpg%su-ai@SU-DSN, steele@CMU-CS-C
Subject: Issues raised by MOON and DLW
In-reply-to: Msg of 28 May 1983 17:22-EDT from David A. Moon <Moon%SCRC-TENEX at MIT-MC>
The response by Guy went out as mail (I think you were an addressee, but
I've deleted that part of it) and is also sitting on CMUC as
PRVA:<SLISP.SCL>LASER.REPLY. I assumed that you had put it there, but I
see that it was Guy who did. Anyway, have a look.
We have large numbers of macros that expand into
implementation-dependent special forms. This is unavoidable. Is this
restriction intended to apply to all macros, or only to macros that are
documented in the Common Lisp manual? If the latter, I'd have to check
carefully, but it is perhaps possible that none of them need to expand
into implementation-dependent special forms.
This only applies to those macros in the manual. Let me know if you
find any screw cases, given this restriction. I think the restriction
makes sense, if there are no screws to be found.
210: I think I've got a problem with APPLYHOOK. This should be
considered controversial and should not go in yet. Could MOON or DLW
send out a definite proposal instead of indirecting through the 4.0
release notes?
I'll send something under separate cover, after I go look at the code.
But it's really very simple.
Well, we don't really call APPLY from within EVAL, exactly. But maybe
if this hook is non-null I can arrange to. I'll have to see the
proposal, as they say.
Right now we just cons &rest args. We don't presently have CDR-coding
anyway. Slow, but I would be unwilling to gain speed by handing the
user a volatile pseudo-list, unless the system could determine when to
de-volatilize it. That just looks too treacherous to me.
Not so! The way you tell whether a symbol has been declared as a constant
with DEFCONSTANT is implementation-dependent. Furthermore the set of
self-evaluating data types is implementation-dependent, because of extensions
to the standard language. I don't think the function is useless, certainly
not in the kind of program-manipulation code I've been writing recently.
The confusion I think derives from one thing: does this function operate
on forms or on objects? It seems clear from its presence in the eval
chapter that it should operate on forms, which means that it should be true
of lists whose car is QUOTE. But its English description isn't written that
way. This seems resolvable.
There are two notions muddled together here. One is whether a symbol is
a constant. We need a portable test for that. The other is whether an
object (or form) can be fed to EVAL and produce itself. It is EVAL's
business how it does that efficiently -- certainly not by calling
something that checks for ''foo or whatever. If the user needs to know
this (why would he?) he can see if (eq x (eval x)), no? Or EQUALP, or
whatever it is that he really wants to know.
Guy has already popped up with the ~E, ~F, ~G proposal, but I now have
to go find a Fortran manual to understand it. He also plans to propose
something for ~S, so that's taken care of.
If no other volunteer appears, I will take a crack at fixing up
pathnames a bit. I was just trying to avoid another situation where you
Symbolics folks end up spending more time criticizing my proposal for
not be what you would have written than you would have spent writing it.
I had the impression that you had some definite ideas about how this
ought to go. Then again, maybe this time I'll get it right on the first
try.
-- Scott
∂30-May-83 0021 RPG Changes to Laser edition for APPLYHOOK
∂28-May-83 1908 FAHLMAN@CMU-CS-C Changes to Laser edition for APPLYHOOK
Received: from SU-DSN by SU-AI with PUP; 28-May-83 19:07 PDT
Received: From CMU-CS-C by SU-DSN.ARPA; Sat May 28 18:28:23 1983
Received: ID <FAHLMAN@CMU-CS-C>; 28 May 83 21:26:40 EDT
Date: Sat, 28 May 1983 21:26 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: David A. Moon <Moon%SCRC-TENEX@MIT-MC>
Cc: DLW%SCRC-TENEX@MIT-MC, RPG%SU-AI@SU-DSN, Steele@CMU-CS-C
Subject: Changes to Laser edition for APPLYHOOK
In-reply-to: Msg of 28 May 1983 18:04-EDT from David A. Moon <Moon%SCRC-TENEX at MIT-MC>
OK, I am in favor of APPLYHOOK given a suitably cleaned-up version of the
documentation. I may have to change around my lexical evaluator a bit,
but I'll get it in.
-- Scott
∂30-May-83 0021 RPG Issues raised by MOON and DLW
∂28-May-83 1908 Moon%SCRC-TENEX@MIT-MC Issues raised by MOON and DLW
Received: from SU-DSN by SU-AI with PUP; 28-May-83 19:08 PDT
Received: From MIT-MC by SU-DSN.ARPA; Sat May 28 18:38:35 1983
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Sat 28-May-83 21:38:52-EDT
Date: Saturday, 28 May 1983, 21:30-EDT
From: David A. Moon <Moon%SCRC-TENEX@MIT-MC>
Subject: Issues raised by MOON and DLW
To: Scott E. Fahlman <Fahlman@CMU-CS-C>
Cc: dlw%SCRC-TENEX@MIT-MC, rpg%su-ai@SU-DSN, steele@CMU-CS-C
In-reply-to: The message of 28 May 83 18:09-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: Sat, 28 May 1983 18:09 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
From: Moon
Not so! The way you tell whether a symbol has been declared as a constant
with DEFCONSTANT is implementation-dependent. Furthermore the set of
self-evaluating data types is implementation-dependent, because of extensions
to the standard language. I don't think the function is useless, certainly
not in the kind of program-manipulation code I've been writing recently.
The confusion I think derives from one thing: does this function operate
on forms or on objects? It seems clear from its presence in the eval
chapter that it should operate on forms, which means that it should be true
of lists whose car is QUOTE. But its English description isn't written that
way. This seems resolvable.
There are two notions muddled together here. One is whether a symbol is
a constant. We need a portable test for that. The other is whether an
object (or form) can be fed to EVAL and produce itself. It is EVAL's
business how it does that efficiently -- certainly not by calling
something that checks for ''foo or whatever. If the user needs to know
this (why would he?) he can see if (eq x (eval x)), no? Or EQUALP, or
whatever it is that he really wants to know.
My interpretation of CONSTANTP is that it tells you whether a form always
evaluates to the same value. I mean by definition, not by elaborate
program analysis. It isn't true of (LET ((X 0)) (DOTIMES (Y 100 X) (INCF X Y)))
nor even of (+ 2 2). It's not whether an object is self-evaluating,
and not whether a symbol has been declared with DEFCONSTANT. So there are
three notions muddled together here. But let's get it straight that we're
talking about a function that is in the language because it's useful to users,
or to the macros that they write. We're not talking about a function that
is called by EVAL in one place.
If no other volunteer appears, I will take a crack at fixing up
pathnames a bit. I was just trying to avoid another situation where you
Symbolics folks end up spending more time criticizing my proposal for
not be what you would have written than you would have spent writing it.
I had the impression that you had some definite ideas about how this
ought to go. Then again, maybe this time I'll get it right on the first
try.
Well, we do have a working multi-host generic pathname system, along
with some ideas of what's wrong with it. And we do have some specific
statements of things that are unworkable about the one in the laser
manual, which might be summed up as slavish, but inexact, copying of (an
older version of) the Lisp machine pathname system without really
understanding it, and logical pathnames that can't be used. Sections 22.2ff
are okay except for maybe a few small nits. But I don't feel able to design
a whole new pathname system right now.
∂30-May-83 0021 RPG Non-ballot
∂28-May-83 1934 FAHLMAN@CMU-CS-C Non-ballot
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 28 May 83 19:33:51 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 28 May 83 22:34:02 EDT
Date: Sat, 28 May 1983 22:34 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: moon%scrc-tenex@mit-mc, dlw%scrc-tenex@mit-mc
Cc: steele@CMU-CS-C, fahlman@CMU-CS-C, rpg@su-ai
Subject: Non-ballot
There are a number of things that appeared in your initial list of
suggestions that, in my opinion, might want to be dropped instead of
appearing on a ballot to Common Lisp. At least, I would like you to
consider dropping these. Any that you feel strongly about keeping will
appear on a ballot, but the more of these issues we can settle without
that, the quicker we will be able to converge. So let me know which of
these you are now willing to drop, if any.
I am assuming that you have read Guy's LASER.REPLY file.
Page 0: I agree that the language would be somewhat better off with
somewhat fewer mumble-p predicates, but I am really inclined to let
sleeping dogs lie on this issue. If you do want to pursue it, please
indicate which predicates should go.
Page 25: I can't believe that a package could ever be a raw hash-table
under the current package plan. I would always be a structure
containing one or more hash-tables, some lists, nicknames, and other
things. So this proposal is now obsolete, I think.
Page 37: In the manual, COERCE takes ARGUMENT, then RESULT-TYPE. Since
the other order is not clearly superior, let's let it be.
Page 38: Coercing of characters to integers is not a very useful
operation in portable code if the langauge spec does not specify the
correspondence (and Common Lisp does not). Do you still want to propose
that we add this coercion? I'm not particularly opposed, I just worry
that users will find it too easy to inadvertently do non-portable things
if given this coercion.
Page 87: Guy seems to have come up with a pretty good reason not to let
TAGBODY drop through with the last value: the last form might be a tag.
Do you still believe that this is the best thing to do? I don't.
Page 99: Do you still think that destructuring DEFMACRO is essential? I
really dislike mixing destructuring and &mumble in the same variable
list. I suppose that this can be made unambiguous, by saying that the &
words are only recognized at top-level in the list, and as soon as one
is seen, no more destructuring is allowed, but that's pretty ugly. What
if we had two flavors of defmacro, one with a lambda-like list and one
with destructuring? Or am I being too conservative here?
Pages 103-105: If you want some sort of declaration (or proclamation)
form whose scope is local to a file, or sometimes is, or whatever,
please make a specific proposal.
Page 164: "Should there be a mroe concise way..." Guy doesn't think so,
neither do I. Do you have a specific proposal to make?
Page 166: "There should be a way..." Again, a proposal would be needed
here if you want to press the issue. I see no great need for an
additional function to do this.
Page 167: I agree with Guy that NSUBSTITUTE should just parallel the
other similar forms.
Page 192: Flush RESET-FILL-POINTER, add FILL-POINTER and SETF of it. I
would be inclined to let it be, but I don't care much either way. Is it
worth the effort?
Page 204: Are you proposing a :named keyword to MAKE-ARRAY, with the
name as the arg, or what?
Page 212: I agree with Guy that to add a special case for not advancing /
and * would be more confusing than not to add this special case.
Page 221: I thought we had voted to flush *IBASE* and just to use #O and
friends to get particular non-decimal constants in. Portable code
should not contain sections that use octal (or whatever) wholesale. If
you really want *IBASE* in Common Lisp, I will give in on this, but at
least we want a strong warning that this should not be used for whole
files or around large sections of code. We've got to break the dead
grip of octal someday.
Page 238: Presumably you have some use in mind for *PRINT-READABLY* ?
I'm curious what you think it is good for.
As I said earlier, if you really want any of these things, I'll put them
on the ballot, though I will oppose some of them. I'm just trying to
keep the number of issues to be publically debated down to a manageable
size.
-- Scott
∂30-May-83 0021 RPG cmuc:prva:<slisp.scl>laser.reply
∂28-May-83 1947 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN cmuc:prva:<slisp.scl>laser.reply
Received: from MIT-MC by SU-AI with TCP/SMTP; 28 May 83 19:46:47 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Sat 28-May-83 22:49:08-EDT
Date: Saturday, 28 May 1983, 22:40-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: cmuc:prva:<slisp.scl>laser.reply
To: Steele%CMU-CS-C@SU-DSN
Cc: Fahlman%CMU-CS-C@SU-DSN, RPG@SU-AI, DLW%SCRC-TENEX%MIT-MC@SU-DSN,
Moon%SCRC-TENEX%MIT-MC@SU-DSN
Discussion of some selected things from that file:
* 38: Coercing of characters to integers should probably be allowed too. -- DLW [not done]
{controversial}
---
I don't think coercion of characters to integers should be allowed, because
how do you know whether you want the char-code or what. Dan was probably
just stuck in our old mindset from not having character objects on the Lisp
machine (we have them now, but only Common Lisp uses them; Zetalisp doesn't).
Coercion of characters to strings, however, I believe is useful.
---
* 49: Also add a note saying how to define a documented variable without giving it
a value (SETF of DOCUMENTATION I guess, bleagh). -- Moon [not done]
---
I'd rather flush variable documentation entirely than require an = between
the variable name and the initial value in the usual case. Maybe SETF of
DOCUMENTATION really is the least ugly way.
---
* 71: The query: good problem. Make it legal to pass unknown keywords?? -- DLW
{controversial}
---
Is my proposed :allow-other-keys kludge an acceptable solution?
---
* 87: a tagbody that drops off the end should return the value(s) of the
last form, rather than nil, since many applications would otherwise need
to wrap a block around it; a simple looping construct that turns into -- Moon [not done]
(TAGBODY initialization NEXT iteration END return-value) is an example.
{Controversial. What is the value in the case
(TAGBODY form1 form2 tag) ? The value of form2, in the drop-through case?
What about when one does a GO to the tag?}
---
I agree now that returning NIL if tagbody falls of the end is better.
Well, all the tagbodys I ever write always have blocks around them it seems,
so maybe I should just be using prog anyway. Except there's no named-prog.
---
182: [gloss] subst is required to make a complete copy of the tree.
I'm not sure I'm happy about this, also nothing is said about whether sublis
makes a copy or not. --Moon
{On the contrary, the second sentence explicitly states that the
result of SUBST may share with the argument tree. Also,
examine the sample code for SUBST. Will clarify SUBLIS.}
---
Sorry about that, that's what I get for reading just the source compare
and not the full text. I checked the full text and it's quite explicit.
---
* 192g: flush reset-fill-pointer, add fill-pointer, and allow setf of fill-pointer. -- Moon
[not done]
{controversial}
---
Really??
---
* 204: How does defstruct create named vectors (second to last paragraph)
if neither make-array nor make-simple-vector takes a :named keyword? It would
be nice for defstruct to be written entirely in the portable language, not
in some magic implementation-dependent language. -- Moon [not done]
{controversial. Make a proposal? Is make-array the right place to
do this?}
---
I think the right thing is for defstruct to call MAKE-VECTOR with the :NAMED
keyword; value is the name. Since MAKE-ARRAY should logically be able to do
anything that MAKE-VECTOR can do, it has to accept a :NAMED keyword also;
probably the array is required to be one-dimensional (unless it has a leader,
but that is going outside of Common Lisp).
---
* 212: When no values are returned, /, //, ///, *, **, and *** should not
be advanced, since nothing was printed. Likewise when execution is
aborted, they should not be advanced. Of course when printing is aborted
they should advance. Since these variables are for people, not for
programs, it is more important that * be the last thing that was printed
than that + and * be kept in sync. -- Moon [not done]
{controversial. I disagree -- parallelism is important, and I think that
/, //, /// should always advance.}
---
Let's be explicit here. If what you think is the following, then not only
are we completely in agreement but (I just checked) that's what our code
does now, modulo having only /, not // and ///.
+, ++, +++ advance if a form was entered. They advance if you
abort out of evaluating, but not if you abort out of reading.
They're funny in that they don't advance until after evaluating,
but they do advance whether or not the evaluation is completed.
/, //, /// advance if evaluation is completed, no matter how many
values are returned.
*, **, *** advance if a value is printed, i.e. evaluation completed
and at least one value was returned. They advance even if printing
is aborted.
This means that there is no guaranteed parallelism between any pair of the
three values +, /, and *. On the other hand, there is guaranteed parallelism
between each of them and what you see on your screen, which I think is much
more important (this was the motivation for our changing a while back so
that *,**,*** wouldn't advance if no values were returned).
Note that I'm repudiating what I said about /,//,/// not advancing if no
values were returned. In retrospect that was wrong.
---
* 222: (table 21-1) # is a non-terminating macro character in the Lisp
machine now. If Common Lisp is going to have them, # should be one. -- Moon [not done]
{controversial}
---
The package system probably requires this, to make #: qualified names parse.
I believe strongly that such "internal qualified names" should be something
a little obscure-looking, and definitely shouldn't be :: (the other obvious
choice) because it doesn't look different enough from a single :.
---
* 233: (#=) It says the scope is "the outermost call to READ". Interaction
between recursive calls to READ is certainly mysterious. Probably there is
a kludge in BREAK to prevent the next READ from thinking it is called recursively.
I'd rather see a different function for macro-character functions that want
to read sub-expressions to call. This would unfortunately imply that
READ-DELIMITED-LIST is illegal for anything but a macro-character to call,
since it has to know which version of READ to use. If we don't add a separate
function, this mysteriosity should be carefully documented. -- Moon [not done]
{hard. I think a separate function will be needed. Alternatively,
how about an extra keyword :recursive to the input functions READ,
READ-PRESERVING-WHITESPACE, and READ-DELIMITED-LIST, which when
true specifies that a new ## scope is not to be made?}
243: Making READ-PRESERVING-WHITESPACE a function rather than a special
variable you bind around a call to READ is nice. However, it brings
up the same problem with recursive calls to READ as #= does (my comment
about that, extracted from my general Laser-edition comments, is enclosed
for reference). Suppose you do (READ-PRESERVING-WHITESPACE)'FOO<space>;
that should preserve the space just as if there were no quote. But if
the quote macro character is defined the way it is in the example on
page 236, this won't happen; the inner call to READ will swallow the space.
If the quote macro character isn't really defined that way, and that is
just an oversimplified pedagogical example, then how are users supposed to
define their own macros? I think the old Maclisp "TYIMAN" family of crocks
are still with us.--Moon [not done]
{Regarding the proposal for a :recursive keyword to READ, perhaps
it would also when true cause the "global preserve-whitespace flag"
not to be altered.}
---
Okay by me: add :recursive and have it affect the preserve-whitespace.
Of course you realize this means all those functions have to be changed
from optional arguments to keyword arguments. If that's unacceptable, make
new functions (only READ and READ-DELIMITED-LIST require two versions, since
the preserving-whitespace distinction isn't relevant on recursive calls,
and no other functions read "S-expression" syntax (as opposed to lines or
characters).
---
238: There should be the equivalent of SI:PRINT-READABLY, which if true causes the
printer to signal an error rather than printing something that READ cannot
understand. (E.g. #<, prinlevel cutoff) -- Moon [not done]
{Another printer variable?}
---
Extracted from a Lisp machine source file. Of course the names should be changed:
;; If this variable bound to non-NIL, then any attempt to print something which
;; cannot be read will signal a PRINT-NOT-READABLE error. Also, objects which
;; do not normally print in a readably, but are indeed able to, will then do so.
(DEFVAR PRINT-READABLY NIL)
; A macro for aiding in the printing of random objects.
; This macro generates a form which:
; 1. Uses the print-table to find the things in which to enclose your randomness.
; 2. (by default) includes the virtual address in the printed representation.
; 3. Obeys PRINT-READABLY
; Options are :NO-POINTER to suppress the pointer
; :TYPEP princs the typep of the object first.
; :FASTP <fastp> if the variable happens to be sitting around.
; Example:
; (DEFSELECT ((:PROPERTY HACKER :NAMED-STRUCTURE-INVOKE))
; (:PRINT-SELF (HACKER STREAM IGNORE IGNORE)
; (SI:PRINTING-RANDOM-OBJECT (HACKER STREAM :TYPEP)
; (PRIN1 (HACKER-NAME HACKER) STREAM))))
; ==> #<HACKER "MMcM" 6172536765>
---
* 240: I think not allowing a package prefix before a vertical-barred symbol
is a dead loss. This affects page 226 (where vertical bar is described)
also. -- Moon
{controversial}
---
Really? You have to switch to backslashes if you happen to want to refer
to an oddly-spelled symbol of another package? How inconsistent.
---
241: In the description of how to print arrays, I think you have left
and right confused. -- DLW
{No, I think it is correct. Examine it carefully.}
---
Son of a gun, I read that this afternoon and I thought it was wrong, and
now I read it again carefully and see that it's right after all. Maybe someone
came in while I was out to dinner and switched manual pages on me--that's
the trouble with looseleaf-bound manuals.
---
245: Does read-char echo on interactive streams? (Probably the answer
is "yes".) --DLW [not done]
{Sigh. Previously there was text to the effect that echoing is done
and people barfed at me. I think they were right at that time:
echoing is a property of the stream, or the interaction of the stream
and the function, not solely of the function.}
---
Yes, the interaction of the stream and the function, with the exact
modularity depending on the implementation. I think this is only
a matter of English, not a Lisp language issue.
---
* 252: ~:A and ~:S should only affect the printing of NIL given directly
as an argument, not the printing of NILs inside a printed list. This is
because these are for printing an object that is known to be a list, not
for printing data so it can be read compatibly into a N.I.L system. -- Moon [not done]
{controversial}
---
Is this really controversial? If we need a feature for printing NIL as ()
that should be a *PRINNIL* (ugh, bletch!) printer-control variable, not a
FORMAT operator. That feature was specifically put into FORMAT for formatting
purposes, not as a substitute for a printer control variable.
NIL (the language) treats NIL (the symbol) the same as everyone
else does these days. Change motivated by Common Lisp compatibility.
---
* 254: ~$ is highly useful and should be put in. Pending a concrete proposal,
I think Fortran ~E, ~F, ~G should be put in. I just looked at a Fortran
manual and they look reasonable, except that 1P should be the default scale
for E and G formats. ~$ is close to ~F but not identical, it would seem. I
doubt that anyone would mind changing "absolute goto" from ~G to ~@*. -- Moon
{controversial. I strongly urge the adoption of FORTRAN-like
floating-point formatting.}
---
Yes. We should definitely do this (need to see a proposal).
---
* 294: apropos should return a list of the symbols found; this can be quite useful.
RMS recently changed his apropos to take arguments [not done]
string &key package superiors inferiors dont-print predicate
Common Lisp might want to adopt something like this, with perhaps keywords
to filter to only variables, only functions. -- Moon
{controversial. Keywords look okay. There is the same problem as with
PPRINT: after the nice-looking stuff has been printed, do you want your
screen garbaged up with the returned list?}
---
Well, we are fixing this whole class of issues via the command processor.
We will no longer confound functions, which programs call, with commands,
which provide nice interfacing to users. At the same time, the two worlds
are very closely tied together, like Siamese twins.
Common Lisp should probably have APROPOS return (VALUES) but dump the
list into a variable, either APROPOS or *APROPOS*. PPRINT should also
return (VALUES).
---
* 298: In what package are the symbols that are elements of *features*? The
Lisp machine uses keywords currently, but compatibility is not an issue here
since the way you get to the list is different. -- Moon [not done]
{controversial}
---
I'm not sure but probably using keywords would cause the least trouble.
Unless it really makes sense to have two features with the same name,
in different packages (all the standard features would be lisp:). I would
be happy either way, perhaps lean about 2% toward non-keywords. But the
manual needs to say which it is.
---
∂30-May-83 0022 RPG :unspecific issues with pathnames
∂28-May-83 1954 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN :unspecific issues with pathnames
Received: from MIT-MC by SU-AI with TCP/SMTP; 28 May 83 19:54:42 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Sat 28-May-83 22:55:51-EDT
Date: Saturday, 28 May 1983, 22:47-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: :unspecific issues with pathnames
To: Steele%CMU-CS-C@SU-DSN
Cc: Fahlman%CMU-CS-C@SU-DSN, RPG@SU-AI, DLW%SCRC-TENEX%MIT-MC@SU-DSN
This text was extracted from the Release 4.0 notes. I hope you'll
forgive me for making you wade through Scribese.
@subsubsection(Meaning of @L[:unspecific] clarified)
@label(unspecific)
In a pathname, a value of @L[:unspecific] for a pathname component now
means that the component is meaningless in the pathname syntax of the
host. The following table shows the conditions under which a pathname
component can be @L[:unspecific].
@SymIndex[sym={:unspecific},key={unspecific}]
@Index[unspecific pathname component]
@begin(desplay)
@i(Component@\Conditions for @L[:unspecific])
Host@\Never
Device@\Always @L[:unspecific] for logical pathnames and pathnames for
Unix, Multics and the Lisp Machine file system.
Directory@\Never (for currently supported hosts)
Name@\Never
Type@\Sometimes @L[:unspecific] on ITS (see section @ref(ITS)). Always
@L[:unspecific] for UNIX and Multics file specs in which a name
component is specified with no period.
Version@\Always @L[:unspecific] for UNIX and Multics pathnames.
Sometimes @L[:unspecific] for ITS (see section @ref(ITS)).
@end(desplay)
Its use is now limited to these cases.
@subsubsection(Generic pathname changes)
@label(generic-pathnames)
Generic pathnames (as returned by the @L[:generic-pathname] message to
@L[fs:pathname]) now have @L[nil] as the type and version instead of
@L[:unspecific]. This was done as part of clarifying the meaning of
@L[:unspecific].
@subsubsection(ITS pathname merging)
@label(ITS)
Pathnames for ITS have been changed so that it is no longer possible to
have two ITS pathnames with the same meaning that differ in an ignored
component. @L[fs:*its-uninteresting-types*] still exists; it controls
which types are ignored in favor of retaining version numbers. The
following table summarizes the interaction of type and version
components for ITS pathnames.
@Index[ITS pathname merging]
@begin(format,longlines wrap, indent +3in)
@newtabs(+1.5in,+1.5in)
@i(Type@\Version@\Result)
supplied@\omitted@\type is retained, version is @L[:unspecific]
omitted@\supplied@\type is @L[:unspecific], version is retained
"interesting"@\supplied@\type is retained, version is @L[:unspecific]
"uninteresting"@\supplied@\type is @L[:unspecific], version is retained
@end(format)
∂30-May-83 0022 RPG Non-ballot
∂28-May-83 2017 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN Non-ballot
Received: from MIT-MC by SU-AI with TCP/SMTP; 28 May 83 20:17:21 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Sat 28-May-83 23:17:33-EDT
Date: Saturday, 28 May 1983, 23:09-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Non-ballot
To: Scott E. Fahlman <Fahlman%CMU-CS-C@SU-DSN>
Cc: dlw%scrc-tenex%mit-mc@SU-DSN, steele%CMU-CS-C@SU-DSN, rpg@su-ai
In-reply-to: The message of 28 May 83 22:34-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: Sat, 28 May 1983 22:34 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
There are a number of things that appeared in your initial list of
suggestions that, in my opinion, might want to be dropped instead of
appearing on a ballot to Common Lisp.
I'll omit any reference to the things that I already sent a message about
a few minutes ago (our messages crossed in the network).
Page 0: I agree that the language would be somewhat better off with
somewhat fewer mumble-p predicates, but I am really inclined to let
sleeping dogs lie on this issue. If you do want to pursue it, please
indicate which predicates should go.
In view of the quotation from the Federalist papers, I'll drop this.
Page 25: I can't believe that a package could ever be a raw hash-table
under the current package plan. I would always be a structure
containing one or more hash-tables, some lists, nicknames, and other
things. So this proposal is now obsolete, I think.
Okay. It was never an issue for our implementation anyway.
Page 37: In the manual, COERCE takes ARGUMENT, then RESULT-TYPE. Since
the other order is not clearly superior, let's let it be.
Okay.
Page 99: Do you still think that destructuring DEFMACRO is essential? I
really dislike mixing destructuring and &mumble in the same variable
list. I suppose that this can be made unambiguous, by saying that the &
words are only recognized at top-level in the list, and as soon as one
is seen, no more destructuring is allowed, but that's pretty ugly. What
if we had two flavors of defmacro, one with a lambda-like list and one
with destructuring? Or am I being too conservative here?
I think you're being too conservative. When an & keyword is seen,
everything to the right of that (within the same list) is in &-keyword
syntax and destructuring no longer applies. This is unambiguous. The
issue is that macros that take some special fields, usually enclosed in
parentheses, followed by "&BODY BODY" are ubiquitous and DEFMACRO
shouldn't force them to parse their arguments by hand (mainly because
that way you wouldn't have a self-documenting "lambda" list). This
feature of DEFMACRO has served us very well over the past few years.
Pages 103-105: If you want some sort of declaration (or proclamation)
form whose scope is local to a file, or sometimes is, or whatever,
please make a specific proposal.
Let's not do anything about this in Common Lisp right now. The issue is
perhaps really that (EVAL-WHEN (COMPILE) ...) doesn't necessarily really
mean "do the same thing as getting into a read-eval-print loop in the
middle of the compiler and evaling this." Some compile-time things are
undone at the end of compilation. But the lexical interpreter (i.e. more
context-sensitivity in the interpreter) makes this a much bigger can of
much squishier worms.
Page 164: "Should there be a mroe concise way..." Guy doesn't think so,
neither do I. Do you have a specific proposal to make?
Drop this, REDUCE is okay as it stands.
Page 166: "There should be a way..." Again, a proposal would be needed
here if you want to press the issue. I see no great need for an
additional function to do this.
[* 166: There should be a way to substitute for subsequences as well as for
single elements as SUBSTITUTE does. --KMP,Moon [not done]
{controversial and hairy}]
No time to do this now, but it's needed and should be in the second edition.
Is it really so hairy?
Page 167: I agree with Guy that NSUBSTITUTE should just parallel the
other similar forms.
Okay.
Page 192: Flush RESET-FILL-POINTER, add FILL-POINTER and SETF of it. I
would be inclined to let it be, but I don't care much either way. Is it
worth the effort?
I think this one is important. RESET-FILL-POINTER is an ugly wart. People
are going to say "well, if LENGTH is how you get the fill-pointer, then why
isn't (SETF (LENGTH ...)) how you set it?" Providing a FILL-POINTER function,
separate from LENGTH and separate from ARRAY-DIMENSION, clarifies the distinction
between the total length of a vector and the length of the valid part, which
is a distinction that you have to understand when changing fill-pointers.
Page 221: I thought we had voted to flush *IBASE* and just to use #O and
friends to get particular non-decimal constants in. Portable code
should not contain sections that use octal (or whatever) wholesale. If
you really want *IBASE* in Common Lisp, I will give in on this, but at
least we want a strong warning that this should not be used for whole
files or around large sections of code. We've got to break the dead
grip of octal someday.
Page 238: Presumably you have some use in mind for *PRINT-READABLY* ?
I'm curious what you think it is good for.
Both of these are for people who use the lisp reader and printer to
manipulate data files (not program source text files).
∂30-May-83 0022 RPG Left and right parentheses
∂28-May-83 2148 Guy.Steele@CMU-CS-A Left and right parentheses
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 28 May 83 21:48:05 PDT
Date: 29 May 1983 0047-EDT (Sunday)
From: Guy.Steele@CMU-CS-A
To: moon%scrc-tenex@MIT-MC, dlw%scrc-tenex@MIT-MC
Subject: Left and right parentheses
CC: rpg@SU-AI, Scott.Fahlman <FAHLMAN@CMU-CS-C>
I am willing to change "left" and "right" to "open" and "close",
but I am also *quite* sure that I don't have left and right backwards.
They may appear to be backwards because the algorithm is not obvious.
There is a bug in the algorithm, which is that incrementation of
dimension j should not output parentheses if j=n (but should still
cause incrementation of dimension j-1 if dimension j overflows).
Consider printing a 2-by-3-by-4 array containing the integers from 0 to 23.
First one prints "#3A" and 3 left parens:
#3A(((
Then elements are enumerated in row-major order until the last dimension
overflows, in this case elements with indices (0 0 0), (0 0 1), (0 0 2),
and (0 0 3):
#3A(((0 1 2 3
When the last dimension overflows, the next-to-last is incremented,
so print a right paren; there is no overflow; then print a left paren:
#3A(((0 1 2 3)(
Now continue to enumerate elements:
#3A(((0 1 2 3)(4 5 6 7
Now print a righ paren; no overflow; a left paren:
#3A(((0 1 2 3)(4 5 6 7)(
Now enumerate more:
#3A(((0 1 2 3)(4 5 6 7)(8 9 10 11
Now print a right paren; the penultimate dimension overflows, so
increment the dimension before that (the first one), which prints
another right paren; that one doesn't overflow; now print a left
paren; now print a left paren for the penultimate dimension:
#3A(((0 1 2 3)(4 5 6 7)(8 9 10 11))((
and so on. Actually, the condition j=n stated above is buggy:
should be j=n-1 to avoid outputting parens (I was in the wrong
origin). Also, I need to amend the algorithm to insert some spaces.
But you can see the general idea.
(I think the fix is: "then if dimension j has not overflowed, print a space,
but if it has overflowed and j>0, then increment dimension j-1".)
--Guy
∂30-May-83 0022 RPG More polished DEFSETF
∂29-May-83 1154 FAHLMAN@CMU-CS-C More polished DEFSETF
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 29 May 83 11:52:17 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 29 May 83 14:52:12 EDT
Date: Sun, 29 May 1983 14:52 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: steele@CMU-CS-C
Cc: rpg@su-ai, moon%scrc-tenex@mit-mc, dlw%scrc-tenex@mit-mc
Subject: More polished DEFSETF
Guy,
Dick Gabriel has polished up some of the wording on Moon's DEFSETF
writeup. The result is in <fahlman.clm>defsetf.mss. I have kept Moon's
original, renamed to defsetf.moon.
Looks like an improvement to me. Nothing substantive has been changed.
This could still use some more work, but it's good enough to ship as is
if we need to. Not too many novice users are going to have to wrestle
with this.
-- Scott
∂30-May-83 0022 RPG Package Chapter
∂29-May-83 1210 FAHLMAN@CMU-CS-C Package Chapter
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 29 May 83 12:10:43 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 29 May 83 15:10:44 EDT
Date: Sun, 29 May 1983 15:10 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: steele@CMU-CS-C
Cc: moon%scrc-tenex@mit-mc, dlw%scrc-tenex@mit-mc, rpg@su-ai,
cellio@CMU-CS-C
Subject: Package Chapter
Guy,
Monica has finished beating the Package Chapter into the proper Scribe
form, and has proofed it through Scribe. It should now be ready to drop
into the manual. In response to Benson's problem in understanding the
case rules, I have added a little not indicating that they are different
from the case rules for symbols. The result is on
<fahlman.clm>package.mss.
The Error chapter should be appearing next, and I already sent you a
pointer to RPG's polished version of DEFSETF.
My next task will be to go through the LASER.REPLY file, indicating
which of those "controversial" issues are now settled, which are
basically settled but require a confirmation, and which are still
unclear. Not too many of the latter.
Home before the leaves fall.
-- Scott
∂30-May-83 0022 RPG More polished DEFSETF
∂29-May-83 1312 @MIT-MC:MOON@SCRC-TENEX More polished DEFSETF
Received: from MIT-MC by SU-AI with TCP/SMTP; 29 May 83 13:11:50 PDT
Date: Sunday, 29 May 1983 16:15-EDT
From: MOON at SCRC-TENEX
To: Scott E. Fahlman <Fahlman at CMU-CS-C>
Cc: dlw%scrc-tenex at mit-mc, moon%scrc-tenex at mit-mc, rpg at su-ai,
steele at CMU-CS-C
Subject: More polished DEFSETF
In-reply-to: The message of Sun 29 May 1983 14:52 EDT from Scott E. Fahlman <Fahlman@CMU-CS-C>
RPG's changes are definite improvements. I made a couple more wording
improvements and fixed some editing spazzes. New version in prva:<slisp.scl>defsetf.mss
∂30-May-83 0022 RPG [Mailer: Message of 29 May 83 18:40:49 EDT]
∂29-May-83 1806 FAHLMAN@CMU-CS-C [Mailer: Message of 29 May 83 18:40:49 EDT]
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 29 May 83 18:06:21 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 29 May 83 21:06:25 EDT
Date: Sun, 29 May 1983 21:06 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: rpg@su-ai
Subject: [Mailer: Message of 29 May 83 18:40:49 EDT]
Date: 29 May 83 18:42:43 EDT
From: The Mailer Daemon <Mailer>
To: <FAHLMAN>
Re: Message of 29 May 83 18:40:49 EDT
Message failed for the following:
rpg@SU-AI: Timed out waiting for FTP reply
------------
Received: ID <FAHLMAN@CMU-CS-C>; 29 May 83 18:40:49 EDT
Date: Sun, 29 May 1983 18:40 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: steele@CMU-CS-C
Cc: moon%scrc-tenex@mit-mc, dlw%scrc-tenex@mit-mc, rpg@su-ai
Subject: Laser.reply
The file <fahlman.clm>laser.reply now contains comments by me indicating
which items I believe to be settled, which will be on the ballot (with
the recommendation I intend to make) and a few things on which I am
totally boggled. Almost everything is either settled or requires mere
confirmation via ballot (unless you folks disagree).
Note that I've got a handful of other issues to add to the ballot that
are not derived from Moon's file, but from other mail. The ballot will
go out sometime tomorrow. Replies will be expected within 3 days or so.
There will probably be a mini-ballot or two after the main one to pick
up stragglers (issus, that is, not people).
-- Scott
∂30-May-83 0022 RPG Laser.reply .reply .reply
∂29-May-83 2021 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN Laser.reply .reply .reply
Received: from MIT-MC by SU-AI with TCP/SMTP; 29 May 83 20:21:26 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Sun 29-May-83 23:24:23-EDT
Date: Sunday, 29 May 1983, 23:16-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Laser.reply .reply .reply
To: Fahlman%CMU-CS-C@SU-DSN
Cc: dlw%SCRC-TENEX%MIT-MC@SU-DSN, Steele%CMU-CS-C@SU-DSN, rpg@SU-AI
14: (table of minimum floating-point precision and range requirements) What
does an implementation on a machine that has no floating-point format that
satisfies one of these requirements do? For instance, the LM-2 has a maximum
floating-point precision of 31 bits. Double and Long modes require 50 bits.
Should the LM-2 provide "bogus" data types with those names, so that programs
that use them will run, inaccurately? Or should it omit those data types
completely? And what about the reader syntaxes?
Perhaps this is on the ballot via other mail, or fixed in the latest manual?
I didn't see anything about it in laser.reply (it got into laser.update later).
* 19: |P 4: [ENDP issue] Is the implementation allowed to cdr down into
an atom, or is the choice only between detecting the error or using an
ATOM test to terminate rather than an ENDP test?
<< Reworded for greater clarity. >>
Presumably resolved by that.
* 192g: flush reset-fill-pointer, add fill-pointer, and allow setf of fill-pointer. -- Moon
[not done]
{controversial}
<< OK, I'll put this on ballot with recommendation that we adopt it.
Just to clarify, FILL-POINTER of a vector is the same as LENGTH of the
vector, but only the former is legal in SETF. Right? >>
FILL-POINTER of a vector returns the same number as LENGTH returns, if
it returns. It "is an error" if the vector wasn't made with the
:FILL-POINTER keyword (thus it is an error for simple vectors).--Moon
<< OK, we need to clarify that CONSTANTP is true of Defconst symbols,
assorted atomic types, keywords, and lists whose CAR is QUOTE, right? >>
Right (given that by Defconst you meant DEFCONSTANT and that this includes
all the builtin ones like NIL, T, and PI).
* 222: (table 21-1) # is a non-terminating macro character in the Lisp
machine now. If Common Lisp is going to have them, # should be one. -- Moon [not done]
{controversial}
Probably needed for #: qualified names.
<< ??? I'm confused about this. Moon seems to be sure that this is
right, but I don't understand the implications. >>
Well, the only implications I know of are that you can use # in a symbol
as long as it isn't at the beginning, and you can use # in a package name
as long as it is neither at the beginning nor at the end. Usually you
shouldn't use it that way, of course. I'm assuming that the #: qualified
name is recognized by recognizing the : in whatever the normal way is, and
then noticing that the last character in the package name is a #.
* 233: (#=) It says the scope is "the outermost call to READ". Interaction
between recursive calls to READ is certainly mysterious. Probably there is
a kludge in BREAK to prevent the next READ from thinking it is called recursively.
I'd rather see a different function for macro-character functions that want
to read sub-expressions to call. This would unfortunately imply that
READ-DELIMITED-LIST is illegal for anything but a macro-character to call,
since it has to know which version of READ to use. If we don't add a separate
function, this mysteriosity should be carefully documented. -- Moon [not done]
{hard. I think a separate function will be needed. Alternatively,
how about an extra keyword :recursive to the input functions READ,
READ-PRESERVING-WHITESPACE, and READ-DELIMITED-LIST, which when
true specifies that a new ## scope is not to be made?}
<< Will put the :recursive keyword (and general conversion of READ
functions to keywords) on the ballot, vs. SUB-READ and
SUB-READ-DELIMITED-LIST. Recommend the former. >>
Of course you realize this means all those functions have to be changed
from optional arguments to keyword arguments. If that's unacceptable, make
new functions (only READ and READ-DELIMITED-LIST require two versions, since
the preserving-whitespace distinction isn't relevant on recursive calls,
and no other functions read "S-expression" syntax (as opposed to lines or
characters).
I just want to make sure the implications of changing the eof-error-p and
eof-value to keywords are thought out. Maybe it should be written up both
ways in the ballot so the voters can see it all laid out.
∂30-May-83 0023 RPG Laser.reply .reply .reply
∂29-May-83 2049 FAHLMAN@CMU-CS-C Laser.reply .reply .reply
Received: from SU-DSN by SU-AI with PUP; 29-May-83 20:49 PDT
Received: From CMU-CS-C by SU-DSN.ARPA; Sun May 29 20:51:31 1983
Received: ID <FAHLMAN@CMU-CS-C>; 29 May 83 23:49:12 EDT
Date: Sun, 29 May 1983 23:49 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: David A. Moon <Moon%SCRC-TENEX@MIT-MC>
Cc: dlw%SCRC-TENEX@MIT-MC, rpg%SU-AI@SU-DSN, Steele@CMU-CS-C,
fahlman@CMU-CS-C
Subject: Laser.reply .reply .reply
In-reply-to: Msg of 29 May 1983 23:16-EDT from David A. Moon <Moon%SCRC-TENEX at MIT-MC>
On 50-bit floating point:
Obvioulsy we cannot require any implementation to supply floating-point
formats of which its hardware is incapable. I think that the table of
minimum requirements for each format has now caused enough trouble that
we should seriously consider deleting it, or at least making it
"suggested minimum lengths".
On ENDP:
I would forbid implementations to use a NULL test if they do not signal
an error on CAR and CDR of an atom. To let the loop roll on through the
guts of an atom is clearly wrong, and efficiency be damned.
On FILL-POINTER:
Thanks for the clarification. I think I favor "signals an error" if you
do FILL-POINTER of an object that doesn't have one, not "is an error".
Is there a problem with this?
On CONSTANTP:
OK, CONSTANTP is true of DEFCONSTANT symbols, built-in constant symbols,
keywords, assorted atomic types, and lists whose CAR is QUOTE.
On # as a non-terminating macro character:
Well, the only implications I know of are that you can use # in a symbol
as long as it isn't at the beginning, and you can use # in a package name
as long as it is neither at the beginning nor at the end. Usually you
shouldn't use it that way, of course. I'm assuming that the #: qualified
name is recognized by recognizing the : in whatever the normal way is, and
then noticing that the last character in the package name is a #.
Mumble. This feels very wrong. Any other opinions out there?
On non-top-level READ, and friends:
I just want to make sure the implications of changing the eof-error-p and
eof-value to keywords are thought out. Maybe it should be written up both
ways in the ballot so the voters can see it all laid out.
The more I think about this, the better I like the idea of leaving the
current READ family alone and adding nearly-identical SUB-READ and
SUB-READ-DELIMTED-LIST for calls from macros. Cleaner. With keywords,
there's a small efficiency question (yes, resolvable by the compiler)
and also the issue of whether the stream argument becomes a keyword or
stays optional. I now want to propose SUB-mumbles.
∂30-May-83 0023 RPG Laser.reply .reply .reply
∂29-May-83 2121 MOON@SCRC-TENEX Laser.reply .reply .reply
Received: from SU-DSN by SU-AI with PUP; 29-May-83 21:21 PDT
Received: From MIT-MC by SU-DSN.ARPA; Sun May 29 21:23:30 1983
Date: Monday, 30 May 1983 00:22-EDT
From: MOON at SCRC-TENEX
To: Scott E. Fahlman <Fahlman at CMU-CS-C>
Cc: dlw at SCRC-TENEX, rpg%SU-AI at SU-DSN, Steele at CMU-CS-C
Subject: Laser.reply .reply .reply
In-reply-to: The message of Sun 29 May 1983 23:49 EDT from Scott E. Fahlman <Fahlman@CMU-CS-C>
Date: Sun, 29 May 1983 23:49 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
In-reply-to: Msg of 29 May 1983 23:16-EDT from David A. Moon <Moon%SCRC-TENEX at MIT-MC>
On 50-bit floating point:
Let's leave the table in but clarify that it's suggested, not required, and
that every implementation will have some numbers with those names, but they
may not conform to the table.
On ENDP:
I would forbid implementations to use a NULL test if they do not signal
an error on CAR and CDR of an atom. To let the loop roll on through the
guts of an atom is clearly wrong, and efficiency be damned.
Okay
On FILL-POINTER:
Thanks for the clarification. I think I favor "signals an error" if you
do FILL-POINTER of an object that doesn't have one, not "is an error".
Is there a problem with this?
No problem for us. We open-code it as (array-leader array 0), but that does
enough run-time checking to signal the error if it's not an array or doesn't
have a fill-pointer. If some implementations want to be able to open-code
fill-pointer and disable error checking, they can use an inline declaration.
On # as a non-terminating macro character:
Well, the only implications I know of are that you can use # in a symbol
as long as it isn't at the beginning, and you can use # in a package name
as long as it is neither at the beginning nor at the end. Usually you
shouldn't use it that way, of course. I'm assuming that the #: qualified
name is recognized by recognizing the : in whatever the normal way is, and
then noticing that the last character in the package name is a #.
Mumble. This feels very wrong. Any other opinions out there?
You really have a strong need to say (funcall#'foo'bar"quux") with no
spaces in between?
∂30-May-83 0023 RPG
Floating point numbers:
I agree that the table ought to be recommended rather than required, at
least for the moment. It is becoming increasingly clear to me that
something will need to be done to accommodate the `hobbyist toys' that
will be running Common Lisp. Until we understand what it is that will be
done, we might as well not aggravate people who will undoubtedly worry
about this issue.
I think that it may happen that we'll have to identify a subset of Common
Lisp that will become somewhat of a programming standard, where this
subset has an efficient implementation on most machines.
ENDP: I agree with the principle, but I would suggest that unsafe declarations
be allowable. Again, this is for the low-end machines.
∂30-May-83 0021 FAHLMAN@CMU-CS-C Memorial Day Ballot
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 30 May 83 00:21:11 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 30 May 83 02:18:55 EDT
Date: Mon, 30 May 1983 02:18 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: common-lisp@su-ai
Subject: Memorial Day Ballot
Memorial Day Ballot:
I was going to send these out in smaller doses, but a bunch of issues
built up and I decided that a real ballot would be easier. A few more
issues will be sent out for consideration as soon as we have come up
with some coherent proposals and analyses. Please reply by Wednesday
afternoon to FAHLMAN@CMUC and/or Common Lisp.
Recommendations in square brackets are by Scott Fahlman.
---------------------------------------------------------------------------
1. It is proposed that we eliminate PARSE-NUMBER from the manual.
[I am strongly in favor of this. This function is hard to document
properly, hard to implement in its full generality, and useless. Most
of what this function does can be handled simply by calling READ on the
string. Other cases, such as Teco-like integer prefixes, can easily be
handled by application-specific user functions to scan a string for the
first non-digit, etc.]
---------------------------------------------------------------------------
2. LOOP should create a BLOCK NIL around the TAGBODY, so that RETURN
works.
[I am strongly in favor. If LOOP doesn't do this, the user will almost
always have to, and any future complex LOOP package would have to create
such blocks as well.]
---------------------------------------------------------------------------
3. Define GET-INTERNAL-TIME to get some implementation-dependent form of
runtime. Add a second function, GET-REAL-TIME that returns some measure
of elapsed real time in the same internal-time format. On some
machines, especially personal ones, these times will be identical, and
implementations may not be able to supply one or the other, but where
both are available (as on the Vax), there are legitimate needs for both.
[I am strongly in favor.]
---------------------------------------------------------------------------
4. The manual currently specifies (page 42, top) that the macros defined
in the white pages macros may expand into implementation-dependent code.
Some of them cannot be written without this freedom, but we don't want
these macros to expand into things that will preclude the writing of
portable code-walkers. Therefore, it is proposed that this wording be
changed to allow implementation-specific functions to be produced, but
not new special forms.
[I am strongly in favor, unless someone comes up with a case where this
restriction would cause serious trouble for an implementation.]
---------------------------------------------------------------------------
5. If the special :allow-other-keys keyword is present in a call to a
keyword-taking function, it suppresses any unrecognized-keyword errors.
This is necessary so that pre-checked keyword lists can be passed
through a keyword-taking function to some other function that is called
by the first one without causing an error.
[I'm in favor.]
---------------------------------------------------------------------------
6. In MULTIPLE-VALUE it is useful to have a way to discard unwanted
values. Since you aren't binding, using and ignored variable is
inconvenient. It is proposed that we follow the Lisp Machine here and
use NIL in place of a variable to mean "ignore this value". For
consistency, this would work in MULTIPLE-VALUE-BIND as well, although it
is less useful there.
[Moon proposed this. I'm mildly in favor, though I've oscillated on
this several times.]
---------------------------------------------------------------------------
7. Eliminate CATCH-ALL and UNWIND-ALL.
[Moon argues that these are worthless and should be flushed. I agree.
These forms make a LOT of trouble for the implementor and are never
used. Does anyone have an example of some real situation in which you
would need these? If not, let's punt them.]
---------------------------------------------------------------------------
8. Since DEFMACRO is used to define special forms, some of which have
complex formats, it is proposed that we add destructuring to DEFMACRO
variable lists. This would have to coexist with the current &mumble
indicators. Destructuring works only to the left of the first & word;
from that point on, the varlist is parsed like a lambda list.
[My conservative instincts rebel at having destructuring and & words in
the same varlist, but I have gradually come around to the position that
this feature is worth any extra confusion it might cause (plus the
trouble of implementing it). The simple cases that would really be used
will not be confusing. So I favor this.]
---------------------------------------------------------------------------
9. It is proposed that DECLARE will be legal only at the start of
particular special forms, and that a new form, PROCLAIM, will be used at
top-level and in other places. DECLARE will be undefined if encountered
in random places (though it may be defined as part of a compatibility
package). The SPECIAL declaration is global if it appears within
PROCLAIM; it applies only to a particular binding and to references
within the scope of the form if it appears within a DECLARE.
[This issue (how to detect when a SPECIAL declaration is "top-level")
was debated on the Common Lisp list awhile back. The proposal above, by
Moon, seemed the least objectionable to most of us at the time, and is
what we have implemented in the new Spice Lisp evaluator. I favor it.]
---------------------------------------------------------------------------
10. The following was proposed by Moon:
The SVREF function and the (SIMPLE-VECTOR *) type are essentially
useless. On stock hardware you cannot open-compile these, because
an implementation is required to provide (SIMPLE-VECTOR T),
(SIMPLE-VECTOR STRING-CHAR), and (SIMPLE-VECTOR BIT) types; hence
SVREF, without additional declarations, must do a run-time type
dispatch. The useful function is SGVREF and the useful type
is (SIMPLE-VECTOR T), because these can be open-coded (and the
only distinction between VECTOR and SIMPLE-VECTOR is efficiency).
The SIMPLE-STRING and SIMPLE-BIT-VECTOR types are also useful,
but don't have special accessor functions.
Another way of putting this is that whether or not MAKE-ARRAY
returns a "simple" object should be allowed to depend on the
:ELEMENT-TYPE as well as the other keywords.
The phrase "simple general vector" is not euphonious.
Here's the proposal:
Retain the identity between the types (VECTOR type length)
and (ARRAY type (length)). In other words, "vector" continues
to be a synonym for "1-dimensional array."
Eliminate SVREF and rename SGVREF to SVREF. Eliminate the
type (SIMPLE-VECTOR type length), replacing it with
(SIMPLE-VECTOR length). In other words, define a SIMPLE-VECTOR
to be a one-dimensional array of Lisp objects, creatable
by calling MAKE-ARRAY with only one dimension and with -none-
of its keywords except for :initial-element/:initial-contents.
In particular use of :element-type (other than T) makes it
non-simple (or, rather, permits the implementation to return
a non-simple-vector object but doesn't require it to. Most
implementations would do the same thing for :element-type 'common
as for :element-type t).
In addition to SIMPLE-VECTOR we have SIMPLE-STRING and
SIMPLE-BIT-VECTOR. Add auto-declaring accessor functions with names
SCHAR and SBIT (or something less horrid), to increase the symmetry.
SIMPLE-STRING is no longer a subtype of SIMPLE-VECTOR, even though
STRING is a subtype of VECTOR. I don't believe this is a problem.
The type-specifier (SIMPLE-ARRAY element-type dimensions) refers to an array
created without the use of the :ADJUSTABLE, :FILL-POINTER, :DISPLACED-TO,
or :DISPLACED-INDEX-OFFSET keywords. Such arrays are implemented
more efficiently in some implementations; thus a SIMPLE-ARRAY type
declaration may be used to get better code for array accesses. Example:
(DEFUN FFT (A)
(DECLARE (TYPE (SIMPLE-ARRAY SINGLE-FLOAT 2) A))
...)
(SIMPLE-VECTOR n) == (SIMPLE-ARRAY T (n))
(SIMPLE-STRING n) == (SIMPLE-ARRAY STRING-CHAR (n))
(SIMPLE-BIT-VECTOR n) == (SIMPLE-ARRAY BIT (n))
The subtle note about declaration vs discrimination on page 33 of the
Laser edition applies.
SAREF probably shouldn't exist, since it would need to include the
element-type as an extra pseudo-argument, which would make the syntax
confusing.
Some implementations will choose to make the extension that :FILL-POINTER
is allowed when making a 1-dimensional simple array, so that they can have
SIMPLE-STRINGs with fill-pointers. I don't know whether the manual ought
to mention this (probably not).
[ Despite my fear of re-opening the array debate, I believe that this is
such a win that it is worth that risk. I am strongly in favor
of this proposal. I just can't bring myself to type SGVREF. ]
---------------------------------------------------------------------------
11. Flush RESET-FILL-POINTER. Add a new function FILL-POINTER, which
returns the active length of any vector that has a fill pointer. This
is the same as what LENGTH returns, but it signals an error if the
object in question doesn't have a fill pointer. SETF works on
FILL-POINTER. The new value must be a non-negative integer not greater
than the dimension of the vector.
[I favor this. RESET-FILL-POINTER is ugly. SETF of LENGTH would be
confusing, since it would only work on a small fraction of the objects
on which LENGTH works.]
---------------------------------------------------------------------------
12. DEFSTRUCT must often created named vectors that are recognizable as
such. There is currently no portable mechanism to do this, so DEFSTRUCT
must use implementation-dependent magic. It would be nice if DEFSTRUCT
could be written entirely within Common Lisp. It is proposed that we
add a :NAMED keyword to MAKE-ARRAY and MAKE-SIMPLE-VECTOR. The argument
is the name itself, a symbol. This argument is only legal if the array
is 1-D.
[I'm in favor.]
---------------------------------------------------------------------------
13. Reintroduce *IBASE*, but with a note that this should be used only
for compatibility packages and for reading files of data with the Lisp
reader. Portable code should contain no regions of non-decimal radix;
individual non-decimal symbols may be read in using #O and friends.
We may want to rename this to *READ-BASE* if proposal 15 is adopted.
[I'm in favor, given these warnings. There will be times when we really
need this.]
---------------------------------------------------------------------------
14. There are a few places where READ and READ-DELIMITED-LIST need to
behave differently according to whether or not they are "top-level"
calls to read. For example, the scope of a set of #n# and #n= bindings
(or is it the extent?) is one top-level call to READ, so READ needs to
know whether it was called at top level or by a read-macro. I propose
that we add two new functions, SUB-READ and SUB-READ-DELIMTED-LIST that
exactly parallel their counterparts, but that indicate non-top-level
calls to read -- such calls do not rebind the ## context, etc.
[I'm in favor. An alternative proposal was to turn all the read
functions into keyword functions and add a :recursive keyword, but this
gets into some efficiency and clarity issues that I would prefer to
avoid.]
---------------------------------------------------------------------------
15. Propose that we rename *PRINfoo* to *PRINT-foo* for all foo, and
that *BASE* be renamed to *PRINT-BASE*. In addition, the names of the
keyword arguments for WRITE would be changed from :PRINfoo to :foo. So
one could say
(WRITE X :BASE 8 :LEVEL 3 :LENGTH 5 :PRETTY T :RADIX T)
Finally, introduce *PRINT-READABLY*, a flag that when true causes
an error to be signalled if the LEVEL or LENGTH cutoff is about to
be applied or if #< syntax is about to be used. That is, it refuses to
print something that cannot be read back in.
[I am strongly in favor of this. The sole virtue of the old names was
Maclisp compatibility, and we blew that when we went for the asterisks.]
---------------------------------------------------------------------------
16. Guy proposes the following treatment of floating point in FORMAT:
~w,d,pF
~w,d,x,pE
~w,d,pG
The meanings of the arguments are exactly as for the FORTRAN-77
language as described in chapter 13 of the FORTRAN-77 standard,
with the following exceptions and extensions:
(a) The scale factor p is an explicit parameter, rather than being
established be a separate preceding directive. For ~F, p defaults to 0,
and for ~E and ~G it defaults to 1. (In FORTRAN p always defaults
to 0.)
(b) If w is omitted, then the output is variable-width, and never
produces a field of asterisks; the other parameters are observed,
however. So "~,2F" will always print exactly two digits after the
decimal point, and prints as many as necessary to the left of
the decimal point.
(c) If d is omitted then as many digits are produced as necessary
to preserve the information content of the number, except that if
w is specified then the width constraint it imposes overrides this
consideration. (Thus if both are omitted we get free-format output.)
(d) The format operation formerly called ~G will henceforth be called ~@*.
(e) A separate proposal regarding ~$ is being developed.
[Looks good to me. Something for everyone, just like Esperanto.]
---------------------------------------------------------------------------
17. Eliminate MAXPREFIX and MAXSUFFIX, which are redundant with
MISMATCH. MISMATCH with non-null :FROM-END returns one plus the
index of the first position (from the right) in which the two sequences
do not match. (The "one plus" is the new part.)
[I am strongly in favor.]
---------------------------------------------------------------------------
18. Moon proposes that we allow vertical bars around a symbol that
follows a : or #: package qualifier.
[I am in favor, unless this is a lot harder to implement than I think it
should be. Do any of you reader-hackers out there have a strong
opinion?]
---------------------------------------------------------------------------
19. ~:A and ~:S should only affect the printing of NIL given directly
as an argument, not the printing of NILs inside a printed list. This is
because these are for printing an object that is known to be a list, not
for printing data so it can be read compatibly into a N.I.L system.
[Proposed by Moon. I'm mildly in favor of this.]
---------------------------------------------------------------------------
20. APROPOS and PPRINT should return NIL so that they can be used at top
level from the terminal without having the returned value clobber the
stuff just printed. Add a new function APROPOS-LIST that hands you a
list of the APROPOS symbols but prints nothing.
[I'm in favor.]
---------------------------------------------------------------------------
21. We need to indicate what package contains the symbols that are used
as elements of *features*. It is proposed that we make these keywords.
[I'm in favor.]
∂30-May-83 0807 FAHLMAN@CMU-CS-C Memorial Day Ballot
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 30 May 83 08:07:01 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 30 May 83 11:07:36 EDT
Date: Mon, 30 May 1983 11:07 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Martin.Griss <Griss@UTAH-20>
Cc: Common-Lisp@su-ai
Subject: Memorial Day Ballot
In-reply-to: Msg of 30 May 1983 08:36-EDT from Martin.Griss <Griss at UTAH-20>
Date: Monday, 30 May 1983 08:36-EDT
From: Martin.Griss <Griss at UTAH-20>
To: Fahlman
cc: Griss at UTAH-20
Re: Memorial Day Ballot
Two things concern me:
a) CATCH-ALL. If flushed, how do we trap a THROW and determine
what its TAG was, so that we can write fancy handlers. We use this in PSL
to trap and resignal Errors etc in the Break loop and some compiler loops.
The manual no longer talks about handlers, but let's assume that you
want something similar to what was described in Laser, perhaps with
extra hair to classify error types heirarchically and catch whole
classes of them at once. You almost certainly want to allow for a thing
that will catch ALL errors and do some specified thing -- throw to the
top-level or whatever. It seems to me that there needs to be a piece of
machinery to keep track of the current condition-to-handler mapping, and
to invoke the proper handler code for each condition that might be
signalled. This might be as simple as an A-list, with (T .
universal-handler) being the "catch-all-errors" widget. In any event,
this mapping determines the proper handler, the system invokes it IN THE
DYNAMIC CONTEXT OF THE ERROR, and it is the handler that does any
throwing. If throw/catch/catch-all is used to do the mapping, then
critical context is lost before the handler ever gets a crack at it. So
I don't think that this is a place where CATCH-ALL is going to be
useful.
b) Name vector for DEFSTRUCT suport. Will this actually be a
diffeernt TYPE?
I don't think named vectors would be a full-fledged type, unless you
define a type to be anything you can test for. All we are suggesting is
that there would be a :named keyword to create these critters and a
NAMED-P test to see if this is what you have. This would be completely
orthogonal to SIMPLE and all of the other hairy properties that vectors
and arrays can have.
-- Scott
∂30-May-83 1205 @USC-ECL:GJC@MIT-ML special characters in package names
Received: from USC-ECL by SU-AI with TCP/SMTP; 30 May 83 12:05:42 PDT
Received: from MIT-ML by USC-ECL; Mon 30 May 83 12:01:45-PDT
Date: 30 May 1983 15:01 EDT
From: George J. Carrette <GJC @ MIT-ML>
Subject: special characters in package names
To: common-lisp @ SU-AI
Something like |;;|: is easy enough to parse as a package prefix.
I would implement this in the NIL reader by putting a PEAK-CHAR
case on the char-macro for |. Of course, a user could already have
typed this in as \;\;: so there is no need to have | behave in
this way. Another thing is that truly-funny package names are
likey to be extremely troublesome in file mode-lines. On the
other hand, presently (INTERN "FOO" (PKG-CREATE-PACKAGE "()"))
prints out as |()|:FOO so for completeness I'd have to go along
with it.
∂30-May-83 1203 Guy.Steele@CMU-CS-A My replies to Memorial Day Ballot
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 30 May 83 12:02:36 PDT
Date: 30 May 1983 1459-EDT (Monday)
From: Guy.Steele@CMU-CS-A
To: fahlman@CMU-CS-C
Subject: My replies to Memorial Day Ballot
CC: common-lisp@SU-AI
I am in favor of all the proposed changes except numbers 6, 14, and 18.
I also have a remark on issue 7.
6: I am not convinced that the bit of convenience in MULTIPLE-VALUE
is worth the odd exception in the syntax, particularly if it is
allowed to propagate to MULTIPLE-VALUE-BIND. Also, just as LET
is in many cases preferable to SETQ anyway, so MULTIPLE-VALUE-BIND
is often preferable to MULTIPLE-VALUE anyway, in which case IGNORE
declarations do the job. Therefore I am opposed to this proposal,
though not strongly.
7: CATCH-ALL and UNWIND-ALL are currently the only means for trapping
any throw and being able to decide what it is. (UNWIND-PROTECT does
not have the latter property.) However, it may be best to omit these
until we have yet more experience with what we really want.
UNWIND-PROTECT does 90% of the job.
14: There are at least three reasons to distinguish a "top-level"
read from an "internal" call:
(a) A top-level call establishes the "preserve whitespace" flag, and
an internal call does not modify it.
(b) A top-level call establishes a scope for the #n= and #n# syntax.
(c) A top-level call establishes the exit point for EOF errors.
While introducing two new functions (copies of the "READ-like" functions)
solves the first two problems, it does not solve the third. It is
also necessary to distinguish betwene top-level and internal calls
to READ-CHAR and READ-LINE and others for the purposes of EOF handling.
Also, it is undesirable for new user-written parsing functions to
have to come intwo flavors. I think it is better to have a standard
simple protocol for distinguishing between top-level and internal calls.
It does seem rather unpleasant to have to go to keyword syntax for all
the input functions.
Here is another possibility: let the eof-errorp parameter take on one
oif three values. NIL means it is an internal call. :VALUE means
that EOF causes the eof-value to be returned. :ERROR means an error
should be signalled. If an "internal call" is performed when there is
no surrounding "top-level" call, then it is as if :ERROR had been
specified. NIL is the default value for eof-errorp.
18: I agree that it is desirable to allow | syntax in package-prefixed names,
but this proposal does not cover all the cases. What about odd characters
in package names? May | syntax be used there too?
I have a counter-proposal. | syntax may surround the *entire name*
of a symbol. It is as if every character between the vertical bars
had been preceded by a \, except for the characters |, \, and (here is
the proposed change!) :. Any occurrence of any of these three characters
must nevertheless always be preceded by a \.
It may seem awful to require any : to be preceded by a \. It would have
been in MacLISP, where |-symbols were also used as strings. This is not
a problem in COmmon LISP.
As an example, the symbol in package "S P A C E S" whose name is
"::=" could be written as |S P A C E S:\:\:=|
The advantage of this proposal is that it allows | to continue to be
an ordinary macro character with screwing up the tokenizer.
Note that that keyword whose name was "foo" (lowercase) would be
written |:foo|, not :|foo|. Vertical bars would always completely
surround the entire other syntax for the symbol, and are described
by the simple rule of quoting every character except |, \, and :.
--Guy
∂30-May-83 1228 WHOLEY@CMU-CS-C Memorial Day Ballot
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 30 May 83 12:28:05 PDT
Received: ID <WHOLEY@CMU-CS-C>; 30 May 83 15:28:34 EDT
Date: Mon, 30 May 1983 15:28 EDT
From: Skef Wholey <Wholey@CMU-CS-C>
To: Scott E. Fahlman <Fahlman@CMU-CS-C>
CC: common-lisp@su-ai
Subject: Memorial Day Ballot
I agree with all your recommendations except for the following issues:
8. Why must destructing live in lambda lists? I think a destructing form would
be much more useful (if you can do destructuring in defmacro's, why not other
places like compiler transforms?). How about a macro DESTRUCTURE, which could
be used like this:
(defmacro new-control-construct (foo &optional bar &rest baz)
(destructure foo (var init iterate-clause)
...))
instead of:
(defmacro new-control-construct ((var init iterate-clause)
&optional bar &rest baz)
...)
?
12. Where would the name be stored? Our DEFSTRUCT uses a special subtype code
to say that the thing's a named structure, and stashes the name in slot 0 of
the vector. So the slots are all "moved up one" into the vector. It seems
that the manual would have to specify something about the implementation, i.e.
where the name is stored.
--Skef
∂30-May-83 1245 Guy.Steele@CMU-CS-A Re: *prindepth* and *prinlength* versus *prinarray*
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 30 May 83 12:44:53 PDT
Date: 30 May 1983 1542-EDT (Monday)
From: Guy.Steele@CMU-CS-A
To: Daniel L. Weinreb <dlw%SCRC-TENEX@MIT-ML>
Subject: Re: *prindepth* and *prinlength* versus *prinarray*
CC: common-lisp@SU-AI
In-Reply-To: "Daniel L. Weinreb's message of 21 Apr 83 10:47-EST"
Page 241 of the Laser manual, under "vectors" and "arrays",
specifically states that printing of vectors and arrays is
affected by *prinlevel* and *prinlength*. Should I put cross-references
to this fact elsewhere?
[Sorry for the delay; I'm just nopw catching up on the May mail deluge.]
--Guy
∂30-May-83 1310 HEDRICK@RUTGERS.ARPA SUB-READ and friends
Received: from RUTGERS by SU-AI with TCP/SMTP; 30 May 83 13:10:18 PDT
Date: Mon 30 May 83 16:13:49-EDT
From: Mgr DEC-20s/Dir LCSR Comp Facility <HEDRICK@RUTGERS.ARPA>
Subject: SUB-READ and friends
To: common-lisp@SU-AI.ARPA
I propose removing this from the ballot pending further discussion.
I agree that the distinction is important. I don't think having two
versions of every function is a delightful way to do it. We have a
similar problem in Elisp. E.g. if a user types ↑F anywhere in the
form, he is supposed to get into the editor to edit it when he
finishes typing all the )))'s. Also there is the EOF problem that has
already been mentioned. What we do is have a separate form READ-CONTEXT.
This is sort of a special-purpose CATCH: it establishes the context to
which EOF should exit and where ↑F should activate. A recursive
call to READ-CONTEXT is a no-op (more or less). This allows us to
write things like READLINE in Lisp. I am not sure that this solves
the problems for Common Lisp, but I do believe we should look for
something better than SUB-READ.
-------
∂30-May-83 1317 @MIT-MC:MOON@SCRC-TENEX Memorial Day Ballot comments
Received: from MIT-MC by SU-AI with TCP/SMTP; 30 May 83 13:16:59 PDT
Date: Monday, 30 May 1983 16:16-EDT
From: MOON at SCRC-TENEX
to: common-lisp at su-ai
Subject: Memorial Day Ballot comments
In-reply-to: The message of Mon 30 May 1983 15:28 EDT from Skef Wholey <Wholey@CMU-CS-C>
Date: Mon, 30 May 1983 15:28 EDT
From: Skef Wholey <Wholey@CMU-CS-C>
8. Why must destructing live in lambda lists? I think a destructing form would
be much more useful (if you can do destructuring in defmacro's, why not other
places like compiler transforms?). How about a macro DESTRUCTURE...
It's important for documentation reasons that the destructuring in a DEFMACRO
be up at the top, not buried inside the body somewhere. To give a simple
example, we have an editor command that prints the argument list of the form
that that the cursor is in. For a macro with complex syntax, you certainly
want this command to tell you about the syntax.
However, you are quite right that the destructuring operation is useful
by itself. We call it DESTRUCTURING-BIND, a rather terrible name.
DEFMACRO is nothing but a convenient packaged combination of MACRO
and DESTRUCTURING-BIND. I haven't proposed DESTRUCTURING-BIND for
Common Lisp recently, because of the name (although it is analogous
to MULTIPLE-VALUE-BIND I guess) and because it might seem too complicated.
12. Where would the name be stored? Our DEFSTRUCT uses a special subtype code
to say that the thing's a named structure, and stashes the name in slot 0 of
the vector. So the slots are all "moved up one" into the vector. It seems
that the manual would have to specify something about the implementation, i.e.
where the name is stored.
Indeed for DEFSTRUCT to be a portable program it has to know whether the
name of a named-vector takes up space in the vector. If the only named
type in the common language is simple (general) vector, then I see no
problems with legislating that the name goes in slot 0. And surely most
implementations would rather do it that way, rather than having named
vectors take on a different storage representation than ordinary vectors.
Of course if you wanted named bit-vectors this wouldn't work, but I see no
need for that by DEFSTRUCT.
Scott, shall we have an auxiliary mini-ballot on these two things?
∂30-May-83 1342 @MIT-MC:MOON@SCRC-TENEX Memorial Day Ballot
Received: from MIT-MC by SU-AI with TCP/SMTP; 30 May 83 13:42:07 PDT
Date: Monday, 30 May 1983 16:44-EDT
From: MOON at SCRC-TENEX
to: common-lisp at su-ai
Subject: Memorial Day Ballot
In-reply-to: The message of Mon 30 May 1983 02:18 EDT from Scott E. Fahlman <Fahlman@CMU-CS-C>
1. Eliminate PARSE-NUMBER Okay. Maybe a new proposal in the future.
2. LOOP => BLOCK NIL Yes.
3. GET-INTERNAL/REAL-TIME Yes, but query below.
4. Macro expansions are portable. I'm going to reserve my vote on this one
until I've studied whether any CL builtin
macros need to expand into imp-dep special
forms, at least in our implementation.
5. :allow-other-keys Yes.
6. (multiple-value (...nil...)...) Yes. Maybe not for MULTIPLE-VALUE-BIND.
7. Flush CATCH-ALL, UNWIND-ALL Yes. Could be put back later if needed.
8. DEFMACRO destructuring. Yes.
9. PROCLAIM Yes. I assume PROCLAIM is a function, not
a special form?
10. SIMPLE-VECTOR holds any object Yes.
also SIMPLE-STRING, SIMPLE-BIT-VECTOR, SIMPLE-ARRAY exist
11. FILL-POINTER Yes.
12. :NAMED in MAKE-ARRAY, MAKE-VECTOR Yes. Element 0 holds the name.
13. *READ-BASE* Yes. If >10, some things that would be
symbols will read as numbers?
14. SUB-READ, SUB-R-D-L I'm reserving my vote while I study GLS's
15. *PRINfoo* => *PRINT-foo* Yes.
16. ~E,~F,~G like in Fortran Yes. You may hear from me after I go
read the Fortran manual to figure out
how ~G differs from ~F.
17. Flush MAXPREFIX,MAXSUFFIX Yes.
18. | : interaction I'm reserving my vote while I study GLS's
19. ~:A vs NIL vs () Yes.
20. APROPOS, PPRINT return NIL Yes. I'd prefer no values, but NIL is okay
21. *features* are keywords Neutral.
---
3. How does GET-REAL-TIME differ from GET-UNIVERSAL-TIME?
How are GET-INTERNAL-TIME and GET-REAL-TIME supposed to be used? Are
they intended for user-interface purposes, in which case they should be
in fairly coarse units, such as seconds, or are they intended for metering
purposes, in which case they should be in rather fine units (same order
of magnitude as the instruction-processing time of the machine, so that
small changes in the performance of a function are visible)? How is the
conflict between trying to keep these numbers small, so that they are
fixnums and arithmetic on them does not noticeably interfere with the
performance of the program being measured, and trying to make them well
behaved numbers that don't "wrap around" to be resolved? Or are all
such issues supposed to be taken care of by the TIME special form, in
which case I have to complain that it prints its output instead of
putting it somewhere where it can be processed by programs? I don't
think we're prepared to design an elaborate Common Lisp instrumentation
system here, but some guidelines would be helpful.
∂30-May-83 1413 KMP@MIT-MC Memorial Day Ballot
Received: from MIT-MC by SU-AI with TCP/SMTP; 30 May 83 14:12:17 PDT
Date: 30 May 1983 16:54 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
Subject: Memorial Day Ballot
To: Fahlman @ CMU-CS-C
cc: Common-Lisp @ SU-AI
Summary
YES on 1-2, 4, 7-16, 19, 21.
NO on 3, 6, 18, 20.
no opinion on 5, 17.
Comments
3. No Do not add GET-INTERNAL-TIME and/or GET-REAL-TIME without
specifying the format of the time. My experience with
code that hacks times says this is frequently worthless
and often dangerous. If the units are unspecified, code
may appear to run while in fact producing bogus results.
I might accept a modified proposal where these functions
were keyworded and implementations could optionally signal
an error for keywords they didn't handle. eg,
(GET-INTERNAL-TIME :MILLISECONDS), etc.
4. Yes Constrain system-provided macros to not expand to
system-dependent special forms. Be careful to word this such
that it's understood that system-dependent macros can be part
of the expansion as long as those macros will eventually
bottom out as system-independent special forms and/or
any kind of function(s).
6. No Actually, if NIL is allowed in place of any variable to be bound or
set meaning IGNORE, I support the proposal. In the absence of such
a restriction, I am swayed by Steele's comments about irregularity.
Maclisp gets much power from allowing NIL in some forms to mean an
ignored argument, but programs which transform code suffer problems
of irregularity in what can go in which binding lists.
7. Yes In fact, if Common Lisp had primitives for creating and
manipulating processes, I would claim that CATCH-ALL and
UNWIND-ALL in some form might be needed. Perhaps, too, if
it specified the implementation of debuggers, complex
error handlers, etc. In the absence of such, however, I
have seen no valid applications for such primitives. Many internal
facilities will be implemented with CATCH/THROW and users will not
be able to recognize what kinds of tags do what things in order to
not screw themselves or thwart important system functionality.
Something like CATCH-ALL or UNWIND-ALL may be needed internally by
a given implementation, but since each implementation will almost
surely use it differently, no attempt should be made to export
or standardize this feature at this time.
8. Yes This is quite useful. Many people prefer destructuring to
&keywords. I recommend, in fact, allowing (DEFMACRO FOO (A . B) ...)
to mean (DEFMACRO FOO (A &REST B) ...) and even
(DEFMACRO FOO X ...) to mean (DEFMACRO FOO (&REST X) ...)
as I'm pretty sure the Maclisp family now allows. Maclisp even allows
(DEFMACRO FOO (&OPTIONAL ((FOO . BAR) '(A . B)) ...) ...)
to work. This, too, can be useful. Then the restriction
wouldn't be "left of &" but would rather be "any place that
is unambiguously reserved for variable names" or some such.
9. Yes This sounds harmless and might do some good.
10. Yes I probably agree with all this. A picture of the type hierarchy this
proposes would be helpful so I'd feel more sure.
12. Yes I dispute the claim that DEFSTRUCT can't already work in a site-
independent way. You could put a unique marker in slot0 of the
defstruct (eg, a gensym whose plist pointed at the real name of the
structure (which would in turn point back at the gensym)). However,
having a primitive named-array facility of some sort would be fine
also.
15. Yes With regard to *PRINT-READABLY*, etc., the manual should give
explicit advice to users saying that they must test this flag
when writing print methods for things that print with #<...>,
otherwise this flag will be of less value.
16. Yes The change to ~G breaks a lot of code, but I suppose the eventual
result is for the better. It will certainly ease the chore of
mechanical translation.
18. No I would like to see a more coherent description of what this means
before I say yes. In general this sounds right, but I'm increasingly
bothered by the off-and-on way we seem to treat package prefixes as
either strings or symbols. There's an argument that says "...", not
|...| should be what's allowed. There are also reasons for believing
|...|:FOO should denote package "/|.../|":FOO, etc. -- at least, under
this vague proposal. I will probably vote yes on this eventually when
a complete, coherent proposal is made.
19. Yes Both styles are occasionally useful, but the only thing you can
usually guarantee the correctness of is the toplevel case. ~:A and
~:S should not be pervasive.
20. No The return value should be left undefined and implementors should
be encouraged not to return anything `big'. On the LispM, it works
well for these sorts of things to return 0 values, since they then
don't clobber the value of "*", and one can do things like
(GET 'FOO 'BAR)
(GPRINT *) ;GPRINT is a pretty printer
(CAR *) ;refers to (CAR (GET 'FOO 'BAR))
If GPRINT returned NIL, * would be clobbered with a useless value.
Specifying that these functions return no values and specifying that
this feature of the read-eval-print-loop happens might be a win.
21. Yes This problem may be more general than just FEATURES, but this is a
good start.
∂30-May-83 1602 @MIT-MC:MOON@SCRC-TENEX Memorial Day Ballot comments
Received: from MIT-MC by SU-AI with TCP/SMTP; 30 May 83 16:02:16 PDT
Date: Monday, 30 May 1983 19:01-EDT
From: MOON at SCRC-TENEX
to: Common-Lisp at SU-AI
Subject: Memorial Day Ballot comments
In-reply-to: The message of 30 May 1983 16:54 EDT from Kent M. Pitman <KMP @ MIT-MC>
Date: 30 May 1983 16:54 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
6. No Actually, if NIL is allowed in place of any variable to be bound or
set meaning IGNORE, I support the proposal.
I think I'd prefer to limit this strictly to MULTIPLE-VALUE, and not try to
allow NIL in place of a variable in MULTIPLE-VALUE-BIND. When I suggested the
latter I hadn't thought through the implications. Making this strictly a
MULTIPLE-VALUE feature should limit the irregularity.
8. (DEFMACRO FOO (&OPTIONAL ((FOO . BAR) '(A . B)) ...) ...)
to work. This, too, can be useful. Then the restriction
wouldn't be "left of &" but would rather be "any place that
is unambiguously reserved for variable names" or some such.
This is a good way to explain it. DEFMACRO, and its underlying primitive
macro DESTRUCTURING-BIND, accept lambda-list syntax except that any tree
can be used where a variable is allowed. Ambiguity, which occurs only after
&OPTIONAL and &KEY, is uniformly resolved in favor of lambda-list syntax.
If our present implementation contains any deviation from this (the only
one I know of is not recognizing &KEY) it is broken and we will fix it.
12. Yes I dispute the claim that DEFSTRUCT can't already work in a site-
independent way. You could put a unique marker in slot0 of the
defstruct (eg, a gensym whose plist pointed at the real name of the
structure (which would in turn point back at the gensym)).
The reason this doesn't work is that the type system is required to understand
named structures, and the type system is built into each implementation.
15. Yes With regard to *PRINT-READABLY*, etc., the manual should give
explicit advice to users saying that they must test this flag
when writing print methods for things that print with #<...>,
otherwise this flag will be of less value.
There's a macro in the Lisp machine to aid in this. I mailed documentation
on it to Fahlman and Steele, perhaps they can make it stylistically consistent
with Common Lisp and put it on a ballot.
∂30-May-83 1707 @MIT-MC:MOON@SCRC-TENEX Issue of macro expansion portability
Received: from MIT-MC by SU-AI with TCP/SMTP; 30 May 83 17:07:41 PDT
Date: Monday, 30 May 1983 19:50-EDT
From: MOON at SCRC-TENEX
To: common-lisp at su-ai
Subject: Issue of macro expansion portability
I went through all the macros in the Common Lisp Summary at the back
of the Laser edition. I know this list is not up to date, and incomplete,
but it's all I have. Almost all the macros there need not expand into
implementation-dependent special-forms, only imp-dep functions and
imp-dep macros that themselves don't expand into imp-dep special forms.
COMPILER-LET, MACRO, and LOCALLY are exceptions, but I believe we already
decided that these are special forms, not macros, and the Laser edition is
in error.
MULTIPLE-VALUE, MULTIPLE-VALUE-BIND, and MULTIPLE-VALUE-LIST are documented
as macros. I guess the intention (contrary to the second to last paragraph
on page 89) must be that these are macros expanding into MULTIPLE-VALUE-CALL
of a lambda-expression, which the compiler then recognizes as a special
case and optimizes. We could do this, but I would greatly prefer not to
have to go through such a song-and-dance in the compiler.
Currently in the Lisp machine DEFVAR expands into code that includes an
implementation-dependent special form. The reason for this, rather than
generating some sort of interpretive code such as
(OR (BOUNDP 'var) (SETQ var val)), has to do with system bootstrapping:
DEFVAR has to expand into code that the cold-load generator can understand,
and it is easier to add a new special form that it understands than to
make it parse some idiom such as OR-BOUNDP-SETQ. This one is only a matter
of convenience and simplicity.
WITH-INPUT-FROM-STRING, WITH-OUTPUT-TO-STRING, and the future condition-handling
macros need to generate data structure of dynamic extent in the stack. This
could be done using functions, but that would involve horrendous gyrations in
the compiler, because it would have to look for uses of those functions
inside of LET, recognizing the particular cases that work and giving an
error for all other cases. Instead, what we did in the Lisp machine was to
add two new special forms, WITH-STACK-LIST and WITH-STACK-LIST*, which provide
a general mechanism for making dynamic-extent data structures (trees, not
arrays). Because these are special forms the compiler can understand them
and generate code for them very easily. The other benefit of this is that
there are a number of user applications that can take advantage of these to
get more efficient execution when they know that a certain data structure is
only going to be used in a dynamic-extent way. Other implementations might prefer
to implement WITH-INPUT-FROM-STRING in a different way, not involving any
data of dynamic-extent, but some implementations will want to do it this way,
so there is a problem.
We could conform to the letter, but not the spirit, of the proposed rule
of no implementation-dependent special forms, by making all of these special
forms into macros with a special kludgey check in the compiler so that it
would not expand them. We could probably come up with some sort of expansion
for them that would satisfy a code-walking program, even though it would
not produce correct code if compiled. I don't really like any sort of
approach along these lines, because suppose you run some code through a
code-walking program which, as a side-effect, expands all macros in the code.
You would naturally be surprised if you discovered that the resulting fully
macro-expanded program did not compile correctly. Even if it produced correct,
but much less efficient, code, you would not be happy.
I would prefer to introduce a handful of additional special forms. An
interesting point to ponder is that all of these special forms are of the
simple sort that my template-driven meta-evaluator (or code-walker) can
understand merely on the basis of templates. They all involve evaluation,
setq'ing, and variable-binding, but they don't involve any unusual flow of
control, other than not processing subforms in left-to-right order
(e.g. MULTIPLE-VALUE evaluates the second subform before it setq's the
variables in the first subform).
Opinions?
∂30-May-83 1718 ALAN@MIT-MC Steele's |:foo| suggestion.
Received: from MIT-MC by SU-AI with TCP/SMTP; 30 May 83 17:18:29 PDT
Date: 30 May 1983 20:18 EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: Steele's |:foo| suggestion.
To: common-lisp @ SU-AI, Guy.Steele @ CMU-CS-A, fahlman @ CMU-CS-C
In-reply-to: Msg of 30 May 1983 1459-EDT () from Guy.Steele at CMU-CS-A
Sorry, I don't find the |S P A C E S:\:\:=| proposal at all tastefull. The
difference between |S P A C E S:\:\:=| and |S P A C E S\:\:\:=| requires a
microscopic examination of the characters to discover.
Given that the common case requires no quoting of the package prefix (on
the LispMachine we went for 6 years before anyone discovered that PRINT had
a deficiency in printing package prefixes that required quoting), I find
the visual distinction between SI:|::=| and |SI:::=| much clearer
than that between |SI:\:\:=| and |SI\:\:\:=|.
I'm sure that if I tried hard enough I could find some problem with
Steele's proposal having to do with the way the case of the quoted package
prefix is treated. Note that his proposal FORCES us to address this issue,
whereas if we keep the package name outside the vbars the issue ONLY arises
with respect to funny characters in package names.
Since people seem to think that it is important to have some rule about
package names with funny characters, I propose that (Common Lisp portable)
packages MUST have names that are composed of letters (case insensitive),
digits, !, $, %, &, *, +, -, <, >, ?, {, }, @, [, ], ↑, ←, and ~. (Or some
suitable similar restriction.)
I do not buy any argument that says SI:|::=| is hard to tokenize. After
the reader has read "SI:" (in fact, immediately after reading ANY unquoted
":") the next thing in the input stream must be the printed representation
of a symbol. In my mind the "token" ended with the reading of the ":", I
realize that this means that you can't just gobble a symbol token, and then
check for occurances of ":", and thus the table on page 222 of the laser
manual needs a new type of syntax. Tough. The extra hours work it takes to
implement it is worth it in my opinion.
∂30-May-83 2200 FAHLMAN@CMU-CS-C ballot issues
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 30 May 83 21:58:31 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 31 May 83 00:58:44 EDT
Date: Tue, 31 May 1983 00:58 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: steele@CMU-CS-C
Cc: common-lisp@su-ai
Subject: ballot issues
Guy,
I like the spirit of your proposal to distinguish internal and top-level
calls to READ through the use of flags passed in through EOF-ERRORP, but
there are a couple of problems. First, EOF-ERRORP is no longer a "p" --
there are three values, and the action comes from two non-null flags.
Second, EOF-ERRORP is no longer just about errors. As you point out,
top-levelness controls a couple of other issues as well. So I think
that leaving the name as it is would be very confusing.
What about the following:
Leave all the read forms just as is, but add a new optional argument
RECURSIVE-P at the end. (This goes on all the read functions that
currently have EOF-ERRORP and EOF-VALUE.) If non-null, this indicates a
recursive (non-"top-level") call. In such cases, the function's
EOF-ERRORP and EOF-VALUE are ignored and should be NIL. The top-level
call's arguments determine the EOF action.
This makes it possible to get the desired effect without new functions
and without going to keywords in all of these functions. As a general
rule, a function with this many flags would want to be converted to
keywords, but the casual user would almost always take the default for
the last arg, or even the last three args.
As for your vertical bar proposal, I don't like it much. I see no
reason for package names to sprout all the syntactic hair that symbols
have. It seems to me that the reader gobbles down the characters
forming a token, treats any unslashed : or #: as terminating the token,
and if these particular terminators are seen, it takes the token-so-far
and treats it (verbatim) as a package-name string rather than doing the
slashified upcasing and treating it as a symbol. If the reader wants to
do the symbol-upcasing as it reads in the characters, this means that it
has to stash away the original characters as well -- not too bad.
Just to avoid any confusion, I would forbid package names to contain |,
\, : or any whitespace. If you see any of those, and then the : or #:
terminator, signal an error. Why go to the trouble of providing the
user with a way to get these into package names, just so that horribly
confusing situations can be created?
The alternative would be to treat case identically in all parts of a
qualified symbol: upcase things not slashified and do a case-sensitive
match. Then |'s around the whole thing or around either half would be
OK. But since there is no tradition of using package names for
pseudo-strings and other randomness, I would prefer to keep them free of
this machinery.
-- Scott
∂30-May-83 2232 @MIT-MC:kmp@MIT-MC Package names
Received: from MIT-MC by SU-AI with TCP/SMTP; 30 May 83 22:32:31 PDT
Date: Tuesday, 31 May 1983, 01:34-EDT
From: Kent M. Pitman <kmp at MIT-MC>
Subject: Package names
To: Common-Lisp at SAIL
I dislike restrictions on what can go into package names. Tradition in Lisp
syntax is to not restrict the language due to the syntax. Restrictions
should not be made on what characters may appear in a package name any
more than they should be made about what can go into a string. Can you
imagine the irritation of being told you can't use NUL in a string because
it's being used for an end of string designator. Having to remember which
N chars can't be used in package names would be very irritating and would
drip too much of yielding to a particular syntax when a strong premise of
Lisp is that syntax is not wired. How about if we say that the tokenizer
scans the package id just as any symbol (allowing vbars) so that
|()|:FOO is legal. It will then look up the package (using case insensitive
lookup of (SYMBOL-NAME the-package-symbol-thing-we-just-read)). You can declare
a package using a string so case can be designated at that time. On output,
the exact case of that declared name will be used and a special hack will be
put in the printer such that |...| will be removed from mixed-case things
where they would normally be retained. eg,
|Abc|:|Abc| would print as Abc:|Abc| (same as ABC:|Abc| and abc:|Abc| and
a/bc:A/b/c, etc. assuming the package was declared with "Abc" as
its name).
Are there any problems with such a scheme? I really think it's essential that
we not get cornered into prohibiting certain chars as people seem to be
suggesting.
-kmp
∂30-May-83 2235 FAHLMAN@CMU-CS-C Ballot clarifications
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 30 May 83 22:34:04 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 31 May 83 01:33:58 EDT
Date: Tue, 31 May 1983 01:33 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: MOON%SCRC-TENEX@mit-mc
Cc: common-lisp@su-ai
Subject: Ballot clarifications
In-reply-to: Msg of 30 May 1983 16:44-EDT from MOON at SCRC-TENEX
A couple of things that you asked about in your ballot:
You ask whether, if *IBASE* (or *READ-BASE*) is > 10, some things that
would otherwise be symbols would be read in as numbers. I think that
the guiding philosophy here should be the one you proposed: *IBASE* is
for reading in data files through the Lisp reader (and maybe for
compatibility packages) and not for code. In a compatibility package
(for code from Maclisp or @i[Cadropithecus robustus]), the issue does
not arise, since the IBASE in question is octal. In reading data, the
rule should be that if it can be parsed into a number in the current
*IBASE*, it will be; else it is a symbol.
On the GET-REAL-TIME proposal, I'm afraid I didn't explain this very
well. GET-UNIVERSAL-TIME is meant to produce a number that can be
decoded to find the current date and time in absolute terms. This might
take a while to get, so it's useful for finding the current time of day
but not for fine-grained measurement of elapsed time. GET-INTERNAL-TIME
and GET-REAL-TIME are relative times expressed in "internal-time"
format. These are for timing various executions but do not give you any
absolute time. You call one of them twice, subtract, and then divide by
INTERNAL-TIME-UNITS-PER-SECOND to get the elapsed time in seconds. The
number of units per second is chosen to give a reasonable balance
between clock accuracy and fixnum size on a given implementation: the S1
needs a granularity of picoseconds and the Perq can get by with seconds.
My proposal is simply that sometimes you want elapsed runtime and
sometimes you want elapsed clock-on-the-wall time. I was going to
propose calling these GET-ELAPSED-RUNTIME and GET-ELAPSED-REALTIME, but
each call to these functions returns only a single point, not an
interval, so that would be misleading also.
-- Scott
∂30-May-83 2252 FAHLMAN@CMU-CS-C Package names
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 30 May 83 22:52:30 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 31 May 83 01:52:08 EDT
Date: Tue, 31 May 1983 01:52 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Kent M. Pitman <kmp@MIT-MC>
Cc: Common-Lisp@SU-AI
Subject: Package names
In-reply-to: Msg of 31 May 1983 01:34-EDT from Kent M. Pitman <kmp at MIT-MC>
I disagree totally with your view of what would constitute an
unreasonable restriction in package names. There is no parallel here
with what things should be legal in strings. It is no additional
cognitive load on real users to remember that package names are supposed
to look like names: alphanumeric characters stuck together. Only users
who want to poke around beyond the limits of good taste would have to
remember to avoid /, :, |, and whitespace.
I prefer the very simple scheme proposed in my earlier message. I would
go along with a decision to treat package names EXACTLY like symbols
with respect to case and escape conventions. I am adamantly opposed to
introducing yet another set of hairy case conventions for string names.
-- Scott
∂30-May-83 2328 Guy.Steele@CMU-CS-A Yucky proposed | syntax
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 30 May 83 23:28:24 PDT
Date: 31 May 1983 0225-EDT (Tuesday)
From: Guy.Steele@CMU-CS-A
To: common-lisp@SU-AI
Subject: Yucky proposed | syntax
I certainly agree that the proposed | syntax is yucky.
That a keyword named "foo" (lowercase) would come out |:foo|
instead of :|foo| is very yucky. Like the "foo#:bar" syntax,
it was intende to be quite grossly yucky.
It is indeed beyond the bounds of reasonable taste to purposely
invent package names with odd characters in them -- at least for
human consumption. However, time and time again someone has reason
to compute a purposely distasteful thing to be "sure" that no one
will bump into it. That GENSYM names have leading zeros "G0001"
is an example of this.
Moreover, it will certainly be possible to compute package names.
You can compute an arbitrary string and feed it to MAKE-PACKAGE.
It is important, for debugging reasons if no other, to have a
standard way to print in the resulting bizarre situation. But it
doesn't have to be a nice way, and indeed should be awful to
discourage such mucking about.
The advantage of my proposal is that it keeps the tokenizing model
very simple. That's all. Any other proposal I have seen makes
the model for where you break between tokens very complicated.
(For similar reasons I tend to prefer "foo::bar" to "foo#:bar",
but I also agree with Moon that :: is perhaps not yucky enough.)
It is not intended that it be easy, merely possible, to tell
what |S P A C E S:\:\:=| means. Anyone who invents a package named
"S P A C E S" or a symbol named "::=" deserves what he gets.
Before non-terminating macro characters were introduced, the tokenizer
was very simple. Escape characters make things into consituents;
whitespace is ignored; macro characters get executed; and otherwise
gobble constituents until a non-constituent is hit. Period.
N-T macro characters complicated things only slightly. The proposed
syntaxes such as |...|:|...| will require a much more complex model
for the sake of some syntactic prettiness in situations that shouldn't
have to be pretty.
--Guy
∂30-May-83 2335 KMP@MIT-MC Package names
Received: from MIT-MC by SU-AI with TCP/SMTP; 30 May 83 23:35:38 PDT
Date: 31 May 1983 02:35 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
Subject: Package names
To: Fahlman @ CMU-CS-C
cc: Common-Lisp @ SU-AI
In my view, if we do this cleverly, users will never see the funny syntax
and will never know the difference. There is no reason not to handle the
general case. Mind you, I'm not trying to protect people, I'm trying to
protect programs. No human should ever write package prefixes with funny
chars, but it's easy (for me at least) to imagine a program doing so and
the seed it uses for package names may for some reason not want to be
constrained in this way. In this case, as in others, I advocate full
generality precisely so that programs which write programs will not have
to have ugly special cases to get around language glitches. Practically
speaking, though, programs which write programs are becoming more and
more common and the more general the language features, the better we
will be supporting that. Certainly no tasteful programmer would write
(MAPC #'FOO) when he meant NIL, would he? That's not why we support
such; we support it, for the most part, to save special cases in
programs that might output it.
I am firm in my belief on this general issue that language design has an
obligation to be as regular and general as possible. To avoid going in
circles on this point, I won't bother commenting further on this issue
unless I have something substantively different to say. Mine is just one
person's vote, but it strongly opposes any outcome which disallows certain
characters in an attempt to make up for ideosyncracies of the particular
read syntax chosen.
-kmp
∂31-May-83 0009 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN yucky package names
Received: from MIT-MC by SU-AI with TCP/SMTP; 31 May 83 00:08:17 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Tue 31-May-83 03:09:17-EDT
Date: Tuesday, 31 May 1983, 03:02-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: yucky package names
To: common-lisp@SU-AI
Perhaps I haven't grasped the point of the recent discussion, but I
don't see why what the Lisp machine reader does now doesn't satisfy
everyone's needs. What it does is extremely simple: slashes are allowed
in package names. That's it. Any sequence of constituent characters,
including slashified characters, ending in a colon is a package prefix.
The other thing it does is that anything that is a symbol by itself is
still a symbol if it follows a colon. That is why :|foo| works.
Okay, I admit it: there's a bug. The printer doesn't remember to put the
slashes in on output, so if you make a package with funny characters in
its name, print symbols from that package with qualified names, and try
to read them back in, you lose. This should be fixed, of course.
∂31-May-83 0014 FAHLMAN@CMU-CS-C Non-yucky package names (I think)
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 31 May 83 00:14:25 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 31 May 83 03:14:34 EDT
Date: Tue, 31 May 1983 03:14 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Common-Lisp@su-ai
Subject: Non-yucky package names (I think)
In-reply-to: Msg of 31 May 1983 0225-EDT () from Guy.Steele at CMU-CS-A
New proposal:
Flush the rules for package-name caseification that are found in the
current package chapter. Replace it with the following:
With respect to case, reading, and printing, package names are treated
EXACTLY like symbol names: upcase by default, escape that using / or ||,
observe *PRINT-CASE* on printing, look up using case-sensitive matching.
Note, however, that package names do not become symbols, but are
stashed away in the package object as a string, after case conversion
paralleling that for symbol-names.
So the reader reads a token in just as if it were a symbol. If it hits
a : or #:, it doesn't call INTERN on the token just collected, but
instead calls FIND-PACKAGE. Then it reads the following token, which
had better be a symbol, and interns it.
The various package functions that take package-name strings should
probably take symbol-or-string. If a symbol, you get the
case-conversion for free but create a random symbol in the current
package; if a string, you have to be careful of case.
So, |fOo:BaR| would be a symbol containing a colon, but |fOo|:|BaR|
is symbol |BaR| in package |fOo|. Notice that I have nothing up my
sleeves and at no time did my hands ever leave the keyboard.
What we lose is the cute preservation of original case in package names
and the ability to toss around package-name strings without worrying
about case. What we gain is a lot of uniformity: both halves of a
symbol behave the same way.
-- Scott
∂31-May-83 0240 @SU-SCORE.ARPA:JONL.PA@PARC-MAXC.ARPA Holiday Ballot
Received: from SU-SCORE by SU-AI with TCP/SMTP; 31 May 83 02:40:05 PDT
Received: from PARC-MAXC.ARPA by SU-SCORE.ARPA with TCP; Tue 31 May 83 02:43:41-PDT
Date: 31 MAY 83 02:35 PDT
From: JONL.PA@PARC-MAXC.ARPA
Subject: Holiday Ballot
To: Fahlman@CMUC.ARPA
cc: Common-Lisp%SU-AI@SCORE.ARPA
Summary:
YES -- 2,4,7,14,16,18
YES, but ... -- 5,6,8
NO -- 9,17,20
No comment on remainder
Why "NO":
9 - PROCLAIM is still unnecessary -- our discussions showed that
it is a trivial matter of programming for Evaluator, Compiler,
and code analyzers to detect the DECLARE as a syntactic part
of a binding context (e.g., LAMBDA or PROG). Do we need more
ways to do the same thing just because some system implementor
couldn't think of how to do this S.M.O.P.? (Small Matter Of ...)
17 - There are two completely independent items here, and they should
*not* be bundled into one ballot question. Eliminating the
redundant MAXmumbles hardly needs a ballot, since it has been
in the mails and no one seems to object to their demise.
20 - I think the 0-return-values solution is better.
Why "but ..."
5 - What about functions that don't pass their keylist on; e.g.
MAKE-ARRAY ? Is it really true that :allow-other-keys will
have the proposed meaning in *every* keyword-taking function?
6 - I like KMP's arguments; the issue is one of uniformity. See
the note "Spread Uniformity" below. Focusing on MULTIPLE-VALUE
is far to limited a perspective -- I'd prefer this were extended
to all LAMBDA position, just like MacLisp.
8 - Same comments as for 6.
Additional comments on "YES"
2 - Is this actually a change from the current implementation of LOOP?
I wonder, why wasn't RPG's suggestion about the MAP series of functions
added to the ballot here; it would imply a somewhat incompatible change
the way MAP etc are implemented in MacLisp, and as such is certainly
deserving of a place on the ballot.
14 - I've written a number of readers in Lisp, and found the SUB-READ
functionality just the thing for improving efficiency of macro
characters (and similar things in the # repetoire). Upon entry to
READ, a number of items may be checked for consistency, and some
particular values may want to be "cached" in global variables; there
is no reason for the recursive-entries to do this.
Spread Uniformity:
The meaning of a lambda-list for DEFUN, for lambda forms, and
for DEFMACRO ought to be perceptually the same, namely it represents
a way to take a sequence/list of items and "spread" them out into
"slots". Historically, these slots were non-NIL symbols; in late
1978, MacLisp (and later NIL) extended the notion of "slot" to admit
NIL, meaning "ignore", and any descendable S-expression, meaning
"destructure" the item spread into this slot. The competitor to this
plan was the "Program-oriented destructuring"; although it has some
good points, it seems to have dropped out of view during the past several
years
In case you don't remember, the "Data-oriented" version says
that the "slot" is a pattern whose non-NIL leaves are symbols to be
bound to the corresponding value selected from the data item; the
"Program-oriented version" says that the "slot" is a program which
would build up the data item if all its accessor parts had the
right value. Example
(LET (((A B) X)) ...) ;Data, or pattern, oriented
(LET ((`(LIST ,A ,B) X)) ...) ;Program oriented version
both would bind A to (CAR X) and B to (CADR X).
Note that the Data-oriented version is not limited to lists:
(LET ((#(A (B . #(C D)) F) X)) ...)
But the "Program-oriented version is even more general:
(LET ((`(GET ,B 'MUMBLE) X)) ...)
That is, it would be possible to indicating a binding to *any*
LOCFable place, and not just to symbol values. [Apologies if I've
mistated the format, or capabilities of the "Program-oriented version",
but I don't think the actual details matter that much]
The point of bringing all this up again is that to "fix" one of
the places that does "spreading" and not "fix" the other places
correspondingly is to perpretate a fairly gross and pointless
inconsistency. [MacLisp failed to generalize SETQ, but instead provided
the macro DESETQ; as it turned out, all the "destructuring" was done
essentially by macro-expansions which used very primitive operations.]
Especially is this matter of uniformity important for auto-documentation.
Interlisp has an extremely useful capability in its reader -- the ?=
macro -- which access the argument list of the function you are about
to type arguments to; e.g., typing
(CONS 3 ?=
causes the informative typeout
(CONS CarArgumentName = 3
CdrArgumentName )
so that you can see the names in the lambda list. (actually, the
argument names for CONS are typically X and Y, but witht he use of
SMARTARGLIST . . . ). Wouldn't it be nice if you could write
(DEFUN FOO ((A B) C) ...)
rather than
(DEFUN FOO (L C) (PROG ((A (CAR L)) (B (CADR L))) ...))
so that ?= type of helpers would show you more about the syntax
of input arguments?
What a loss if such facility worked for DEFUN definitions, but
not for DEFMACRO definitions (and vice-versa)!
∂31-May-83 0548 @USC-ECL,@MIT-MC:BSG%SCRC-TENEX@MIT-MC A memorial day issue
Received: from USC-ECL by SU-AI with TCP/SMTP; 31 May 83 05:48:10 PDT
Received: from MIT-MC by USC-ECL; Tue 31 May 83 05:44:43-PDT
Date: 31 May 1983 0843-EDT
From: Bernard S. Greenberg <BSG%SCRC-TENEX@MIT-MC>
Subject: A memorial day issue
To: common-lisp%su-ai@USC-ECL
Although the current PARSE-NUMBER is unworkable, the original idea has
a legitimate place, and satisfies a legitimate need, in the language.
Before coming to the Lisp Machine (which has a PARSE-NUMBER which is
really PARSE-INTEGER), every program that interacted with a user
which I had written required writing such a routine. It seems inevitable
that any program that reads strings from a user would require such a
routine, so, thus, it ought be part of the language.
READ will not do the trick. READ cannot implement a subsystem's
contract on what the subsystem's legal input is. Syntactic errors
in typing a number should be detectable in a portable fashion without
recourse to trapping READ errors (e.g., unbalanced parens in read-from-string).
READ can be forced to produce odd side-effects via #. .
Rename and respecify PARSE-NUMBER to PARSE-INTEGER.
-------
∂31-May-83 0642 @USC-ECL:FAHLMAN@CMU-CS-C A memorial day issue
Received: from USC-ECL by SU-AI with TCP/SMTP; 31 May 83 06:42:26 PDT
Received: from CMU-CS-C by USC-ECL; Tue 31 May 83 06:39:09-PDT
Received: ID <FAHLMAN@CMU-CS-C>; 31 May 83 09:37:41 EDT
Date: Tue, 31 May 1983 09:37 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Bernard S. Greenberg <BSG%SCRC-TENEX@MIT-MC>
Cc: common-lisp%su-ai@USC-ECL
Subject: A memorial day issue
In-reply-to: Msg of 31 May 1983 08:43-EDT from Bernard S. Greenberg <BSG%SCRC-TENEX at MIT-MC>
Send a specific proposal for PARSE-INTEGER and then we can consider it.
My specific proposal is that we flush it. I still don't see any
function in here that would be broadly and generally useful and not
trivial for the user to write, but you've written more user interfaces
than I, and if there's a good idea in here trying to get out, I'd like
to see it.
I note in passing that a lot of interfaces from MIT have been strongly
influenced by the syntactic style of TECO and DDT: 123x, etc. This
style has its place (in programs like TECO and DDT), but there are much
better user interface styles around for most things, or at least a lot
of variety in people's taste. So if the proposed PARSE-INTEGER were
primarily intended to make it easier to parse the "abutted numeric
prefix" style of argument, I think it would be a great candidate for the
yellow pages but I would oppose its inclusion in the white pages.
-- Scott
∂31-May-83 0643 FAHLMAN@CMU-CS-C A memorial day issue
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 31 May 83 06:43:26 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 31 May 83 09:42:23 EDT
Date: Tue, 31 May 1983 09:42 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Bernard S. Greenberg <BSG%SCRC-TENEX@MIT-MC>
Cc: common-lisp@su-ai
Subject: A memorial day issue
Send a specific proposal for PARSE-INTEGER and then we can consider it.
My specific proposal is that we flush it. I still don't see any
function in here that would be broadly and generally useful and not
trivial for the user to write, but you've written more user interfaces
than I, and if there's a good idea in here trying to get out, I'd like
to see it.
I note in passing that a lot of interfaces from MIT have been strongly
influenced by the syntactic style of TECO and DDT: 123x, etc. This
style has its place (in programs like TECO and DDT), but there are much
better user interface styles around for most things, or at least a lot
of variety in people's taste. So if the proposed PARSE-INTEGER were
primarily intended to make it easier to parse the "abutted numeric
prefix" style of argument, I think it would be a great candidate for the
yellow pages but I would oppose its inclusion in the white pages.
-- Scott
∂31-May-83 0754 jrg@cmu-cs-spice Memorial Day Ballot
Received: from RANDOM-PLACE by SU-AI with TCP/SMTP; 31 May 83 07:53:46 PDT
Date: Tuesday, 31 May 1983 10:49:13 EDT
From: Joseph.Ginder@CMU-CS-SPICE
To: fahlman@cmuc
cc: common-lisp@su-ai
Subject: Memorial Day Ballot
Message-ID: <1983.5.31.14.5.18.Joseph.Ginder@CMU-CS-SPICE>
1. Y
2. Y
3. Y; with unit keywords (eg. microseconds)
4. Y
5. Y
6. no opinion
7. Y
8. Y (shudder)
9. Y
10. Y (It seems a shame to make "simple" denote "any lisp object but no
bells and whistles"; however, I don't have a better idea other than
equating "vector" with "no bells and whistles". Sigh.)
11. Y
12. Y
13. Y
14. recursive-p version
15. Y
16. no opinion
17. Y
18. Y (I detest losing input case information; but agree that symbols' halves
should be treated the same. Note that I did not say I wanted case
sensitivity!)
19. no opinion
20. Y
21. no opinion
∂31-May-83 0857 @USC-ECL,@MIT-MC:BSG%SCRC-TENEX@MIT-MC A memorial day issue
Received: from USC-ECL by SU-AI with TCP/SMTP; 31 May 83 08:57:27 PDT
Received: from MIT-MC by USC-ECL; Tue 31 May 83 08:58:37-PDT
Received: from SCRC-BULLDOG by SCRC-TENEX with CHAOS; Tue 31-May-83 11:56:40-EDT
Date: Tuesday, 31 May 1983, 11:58-EDT
From: Bernard S. Greenberg <BSG%SCRC-TENEX@MIT-MC>
Subject: A memorial day issue
To: Fahlman@CMU-CS-C
Cc: common-lisp%su-ai@USC-ECL
In-reply-to: The message of 31 May 83 09:37-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: Tue, 31 May 1983 09:37 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
Send a specific proposal for PARSE-INTEGER and then we can consider it.
My specific proposal is that we flush it. I still don't see any
function in here that would be broadly and generally useful and not
trivial for the user to write, but you've written more user interfaces
than I, and if there's a good idea in here trying to get out, I'd like
to see it.
@Defun[Fun {parse-integer}, Args {@i[string]}, Keys {[start][end][radix][junk-allowed]}]
This function examines the substring of @i[string] delimited by @kwd[start]
and @kwd[end] (which default to the beginning and end of the string).
It skips over whitespace characters and then attempts to
parse an integer. The @kwd[radix] parameter defaults to @f[10],
and must be an integer between 2 and 36.
If @i[junk-allowed] is not @false, then the first value
returned is the integer parsed, or @false if no syntactically correct number
was seen. The second value is the index into the string of the delimiter
that terminated the parse, or the index beyond the substring if the
parse terminated at the end of the substring.
If @kwd[junk-allowed] is @false (the default), then the entire substring is scanned.
An error is signalled if the substring does not consist entirely of
the representation of an integer, possibly surrounded on either side by
whitespace characters.
The returned value is the number parsed, or @false if no syntactically valid
integer was found.
It is an error if the substring is blank (@false will be returned in this case).
@Enddefun
I note in passing that a lot of interfaces from MIT have been strongly
influenced by the syntactic style of TECO and DDT: 123x, etc. This
style has its place (in programs like TECO and DDT), but there are much
better user interface styles around for most things, or at least a lot
of variety in people's taste.
I dislike that style of interface intensely, too. PARSE-INTEGER, although
it supports such activity, is not designed primarily with that in mind.
so if the proposed PARSE-INTEGER were
primarily intended to make it easier to parse the "abutted numeric
prefix" style of argument, I think it would be a great candidate for the
yellow pages but I would oppose its inclusion in the white pages.
There is no strict need for a lot of functions. Yet, this particular
little piece of functionality seems like a white pages candidate because,
as I have said, almost any conceivable user interface will require it. The
abutted-number feature is a very small aspect.
I am not sure if whitespace around the number being allowed is right.
∂31-May-83 1043 RPG Memorial Day Ballot
∂30-May-83 0021 FAHLMAN@CMU-CS-C Memorial Day Ballot
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 30 May 83 00:21:11 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 30 May 83 02:18:55 EDT
Date: Mon, 30 May 1983 02:18 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: common-lisp@su-ai
Subject: Memorial Day Ballot
Memorial Day Ballot:
I was going to send these out in smaller doses, but a bunch of issues
built up and I decided that a real ballot would be easier. A few more
issues will be sent out for consideration as soon as we have come up
with some coherent proposals and analyses. Please reply by Wednesday
afternoon to FAHLMAN@CMUC and/or Common Lisp.
Recommendations in square brackets are by Scott Fahlman.
---------------------------------------------------------------------------
1. It is proposed that we eliminate PARSE-NUMBER from the manual.
[I am strongly in favor of this. This function is hard to document
properly, hard to implement in its full generality, and useless. Most
of what this function does can be handled simply by calling READ on the
string. Other cases, such as Teco-like integer prefixes, can easily be
handled by application-specific user functions to scan a string for the
first non-digit, etc.]
Ok
---------------------------------------------------------------------------
2. LOOP should create a BLOCK NIL around the TAGBODY, so that RETURN
works.
[I am strongly in favor. If LOOP doesn't do this, the user will almost
always have to, and any future complex LOOP package would have to create
such blocks as well.]
Ok
---------------------------------------------------------------------------
3. Define GET-INTERNAL-TIME to get some implementation-dependent form of
runtime. Add a second function, GET-REAL-TIME that returns some measure
of elapsed real time in the same internal-time format. On some
machines, especially personal ones, these times will be identical, and
implementations may not be able to supply one or the other, but where
both are available (as on the Vax), there are legitimate needs for both.
[I am strongly in favor.]
Ok.
---------------------------------------------------------------------------
4. The manual currently specifies (page 42, top) that the macros defined
in the white pages macros may expand into implementation-dependent code.
Some of them cannot be written without this freedom, but we don't want
these macros to expand into things that will preclude the writing of
portable code-walkers. Therefore, it is proposed that this wording be
changed to allow implementation-specific functions to be produced, but
not new special forms.
[I am strongly in favor, unless someone comes up with a case where this
restriction would cause serious trouble for an implementation.]
Ok.
---------------------------------------------------------------------------
5. If the special :allow-other-keys keyword is present in a call to a
keyword-taking function, it suppresses any unrecognized-keyword errors.
This is necessary so that pre-checked keyword lists can be passed
through a keyword-taking function to some other function that is called
by the first one without causing an error.
[I'm in favor.]
Ok.
---------------------------------------------------------------------------
6. In MULTIPLE-VALUE it is useful to have a way to discard unwanted
values. Since you aren't binding, using and ignored variable is
inconvenient. It is proposed that we follow the Lisp Machine here and
use NIL in place of a variable to mean "ignore this value". For
consistency, this would work in MULTIPLE-VALUE-BIND as well, although it
is less useful there.
[Moon proposed this. I'm mildly in favor, though I've oscillated on
this several times.]
No.
---------------------------------------------------------------------------
7. Eliminate CATCH-ALL and UNWIND-ALL.
[Moon argues that these are worthless and should be flushed. I agree.
These forms make a LOT of trouble for the implementor and are never
used. Does anyone have an example of some real situation in which you
would need these? If not, let's punt them.]
No (See Steele's comments)
No (See Steele's comments)
---------------------------------------------------------------------------
8. Since DEFMACRO is used to define special forms, some of which have
complex formats, it is proposed that we add destructuring to DEFMACRO
variable lists. This would have to coexist with the current &mumble
indicators. Destructuring works only to the left of the first & word;
from that point on, the varlist is parsed like a lambda list.
[My conservative instincts rebel at having destructuring and & words in
the same varlist, but I have gradually come around to the position that
this feature is worth any extra confusion it might cause (plus the
trouble of implementing it). The simple cases that would really be used
will not be confusing. So I favor this.]
Ok. Presumably some bright fellow will write the code for this, and we
can all use it.
Ok. Presumably some bright fellow will write the code for this, and we
can all use it.
---------------------------------------------------------------------------
9. It is proposed that DECLARE will be legal only at the start of
particular special forms, and that a new form, PROCLAIM, will be used at
top-level and in other places. DECLARE will be undefined if encountered
in random places (though it may be defined as part of a compatibility
package). The SPECIAL declaration is global if it appears within
PROCLAIM; it applies only to a particular binding and to references
within the scope of the form if it appears within a DECLARE.
[This issue (how to detect when a SPECIAL declaration is "top-level")
was debated on the Common Lisp list awhile back. The proposal above, by
Moon, seemed the least objectionable to most of us at the time, and is
what we have implemented in the new Spice Lisp evaluator. I favor it.]
Ok.
Ok.
---------------------------------------------------------------------------
10. The following was proposed by Moon:
The SVREF function and the (SIMPLE-VECTOR *) type are essentially
useless. On stock hardware you cannot open-compile these, because
an implementation is required to provide (SIMPLE-VECTOR T),
(SIMPLE-VECTOR STRING-CHAR), and (SIMPLE-VECTOR BIT) types; hence
SVREF, without additional declarations, must do a run-time type
dispatch. The useful function is SGVREF and the useful type
is (SIMPLE-VECTOR T), because these can be open-coded (and the
only distinction between VECTOR and SIMPLE-VECTOR is efficiency).
The SIMPLE-STRING and SIMPLE-BIT-VECTOR types are also useful,
but don't have special accessor functions.
Another way of putting this is that whether or not MAKE-ARRAY
returns a "simple" object should be allowed to depend on the
:ELEMENT-TYPE as well as the other keywords.
The phrase "simple general vector" is not euphonious.
Here's the proposal:
Retain the identity between the types (VECTOR type length)
and (ARRAY type (length)). In other words, "vector" continues
to be a synonym for "1-dimensional array."
Eliminate SVREF and rename SGVREF to SVREF. Eliminate the
type (SIMPLE-VECTOR type length), replacing it with
(SIMPLE-VECTOR length). In other words, define a SIMPLE-VECTOR
to be a one-dimensional array of Lisp objects, creatable
by calling MAKE-ARRAY with only one dimension and with -none-
of its keywords except for :initial-element/:initial-contents.
In particular use of :element-type (other than T) makes it
non-simple (or, rather, permits the implementation to return
a non-simple-vector object but doesn't require it to. Most
implementations would do the same thing for :element-type 'common
as for :element-type t).
In addition to SIMPLE-VECTOR we have SIMPLE-STRING and
SIMPLE-BIT-VECTOR. Add auto-declaring accessor functions with names
SCHAR and SBIT (or something less horrid), to increase the symmetry.
SIMPLE-STRING is no longer a subtype of SIMPLE-VECTOR, even though
STRING is a subtype of VECTOR. I don't believe this is a problem.
The type-specifier (SIMPLE-ARRAY element-type dimensions) refers to an array
created without the use of the :ADJUSTABLE, :FILL-POINTER, :DISPLACED-TO,
or :DISPLACED-INDEX-OFFSET keywords. Such arrays are implemented
more efficiently in some implementations; thus a SIMPLE-ARRAY type
declaration may be used to get better code for array accesses. Example:
(DEFUN FFT (A)
(DECLARE (TYPE (SIMPLE-ARRAY SINGLE-FLOAT 2) A))
...)
(SIMPLE-VECTOR n) == (SIMPLE-ARRAY T (n))
(SIMPLE-STRING n) == (SIMPLE-ARRAY STRING-CHAR (n))
(SIMPLE-BIT-VECTOR n) == (SIMPLE-ARRAY BIT (n))
The subtle note about declaration vs discrimination on page 33 of the
Laser edition applies.
SAREF probably shouldn't exist, since it would need to include the
element-type as an extra pseudo-argument, which would make the syntax
confusing.
Some implementations will choose to make the extension that :FILL-POINTER
is allowed when making a 1-dimensional simple array, so that they can have
SIMPLE-STRINGs with fill-pointers. I don't know whether the manual ought
to mention this (probably not).
[ Despite my fear of re-opening the array debate, I believe that this is
such a win that it is worth that risk. I am strongly in favor
of this proposal. I just can't bring myself to type SGVREF. ]
S-1 needs this.
S-1 needs this.
---------------------------------------------------------------------------
11. Flush RESET-FILL-POINTER. Add a new function FILL-POINTER, which
returns the active length of any vector that has a fill pointer. This
is the same as what LENGTH returns, but it signals an error if the
object in question doesn't have a fill pointer. SETF works on
FILL-POINTER. The new value must be a non-negative integer not greater
than the dimension of the vector.
[I favor this. RESET-FILL-POINTER is ugly. SETF of LENGTH would be
confusing, since it would only work on a small fraction of the objects
on which LENGTH works.]
Ok.
Ok.
---------------------------------------------------------------------------
12. DEFSTRUCT must often created named vectors that are recognizable as
such. There is currently no portable mechanism to do this, so DEFSTRUCT
must use implementation-dependent magic. It would be nice if DEFSTRUCT
could be written entirely within Common Lisp. It is proposed that we
add a :NAMED keyword to MAKE-ARRAY and MAKE-SIMPLE-VECTOR. The argument
is the name itself, a symbol. This argument is only legal if the array
is 1-D.
[I'm in favor.]
Ok.
Ok.
---------------------------------------------------------------------------
13. Reintroduce *IBASE*, but with a note that this should be used only
for compatibility packages and for reading files of data with the Lisp
reader. Portable code should contain no regions of non-decimal radix;
individual non-decimal symbols may be read in using #O and friends.
We may want to rename this to *READ-BASE* if proposal 15 is adopted.
[I'm in favor, given these warnings. There will be times when we really
need this.]
Ok.
---------------------------------------------------------------------------
14. There are a few places where READ and READ-DELIMITED-LIST need to
behave differently according to whether or not they are "top-level"
calls to read. For example, the scope of a set of #n# and #n= bindings
(or is it the extent?) is one top-level call to READ, so READ needs to
know whether it was called at top level or by a read-macro. I propose
that we add two new functions, SUB-READ and SUB-READ-DELIMTED-LIST that
exactly parallel their counterparts, but that indicate non-top-level
calls to read -- such calls do not rebind the ## context, etc.
[I'm in favor. An alternative proposal was to turn all the read
functions into keyword functions and add a :recursive keyword, but this
gets into some efficiency and clarity issues that I would prefer to
avoid.]
No. I favor Steele's suggestion.
No. I favor Steele's suggestion.
---------------------------------------------------------------------------
15. Propose that we rename *PRINfoo* to *PRINT-foo* for all foo, and
that *BASE* be renamed to *PRINT-BASE*. In addition, the names of the
keyword arguments for WRITE would be changed from :PRINfoo to :foo. So
one could say
(WRITE X :BASE 8 :LEVEL 3 :LENGTH 5 :PRETTY T :RADIX T)
Finally, introduce *PRINT-READABLY*, a flag that when true causes
an error to be signalled if the LEVEL or LENGTH cutoff is about to
be applied or if #< syntax is about to be used. That is, it refuses to
print something that cannot be read back in.
[I am strongly in favor of this. The sole virtue of the old names was
Maclisp compatibility, and we blew that when we went for the asterisks.]
Ok.
Ok.
---------------------------------------------------------------------------
16. Guy proposes the following treatment of floating point in FORMAT:
~w,d,pF
~w,d,x,pE
~w,d,pG
The meanings of the arguments are exactly as for the FORTRAN-77
language as described in chapter 13 of the FORTRAN-77 standard,
with the following exceptions and extensions:
(a) The scale factor p is an explicit parameter, rather than being
established be a separate preceding directive. For ~F, p defaults to 0,
and for ~E and ~G it defaults to 1. (In FORTRAN p always defaults
to 0.)
(b) If w is omitted, then the output is variable-width, and never
produces a field of asterisks; the other parameters are observed,
however. So "~,2F" will always print exactly two digits after the
decimal point, and prints as many as necessary to the left of
the decimal point.
(c) If d is omitted then as many digits are produced as necessary
to preserve the information content of the number, except that if
w is specified then the width constraint it imposes overrides this
consideration. (Thus if both are omitted we get free-format output.)
(d) The format operation formerly called ~G will henceforth be called ~@*.
(e) A separate proposal regarding ~$ is being developed.
[Looks good to me. Something for everyone, just like Esperanto.]
Ok.
Ok.
---------------------------------------------------------------------------
17. Eliminate MAXPREFIX and MAXSUFFIX, which are redundant with
MISMATCH. MISMATCH with non-null :FROM-END returns one plus the
index of the first position (from the right) in which the two sequences
do not match. (The "one plus" is the new part.)
[I am strongly in favor.]
Ok.
Ok.
---------------------------------------------------------------------------
18. Moon proposes that we allow vertical bars around a symbol that
follows a : or #: package qualifier.
[I am in favor, unless this is a lot harder to implement than I think it
should be. Do any of you reader-hackers out there have a strong
opinion?]
??
---------------------------------------------------------------------------
19. ~:A and ~:S should only affect the printing of NIL given directly
as an argument, not the printing of NILs inside a printed list. This is
because these are for printing an object that is known to be a list, not
for printing data so it can be read compatibly into a N.I.L system.
[Proposed by Moon. I'm mildly in favor of this.]
??
---------------------------------------------------------------------------
20. APROPOS and PPRINT should return NIL so that they can be used at top
level from the terminal without having the returned value clobber the
stuff just printed. Add a new function APROPOS-LIST that hands you a
list of the APROPOS symbols but prints nothing.
[I'm in favor.]
Ok.
---------------------------------------------------------------------------
21. We need to indicate what package contains the symbols that are used
as elements of *features*. It is proposed that we make these keywords.
[I'm in favor.]
Ok.
∂31-May-83 1205 DDYER@USC-ISIB memorial ballot
Received: from USC-ISIB by SU-AI with TCP/SMTP; 31 May 83 12:05:12 PDT
Date: 31 May 1983 1201-PDT
Subject: memorial ballot
From: Dave Dyer <DDYER@USC-ISIB>
To: common-lisp@SU-AI
1. Eliminate PARSE-NUMBER Yes.
2. LOOP => BLOCK NIL Yes.
3. GET-INTERNAL/REAL-TIME Yes.
4. Macro expansions are portable. Yes.
5. :allow-other-keys No opinion
6. (multiple-value (...nil...)...) Yes, and YES for multiple valuebind as
Why should I have write my own LET when
i want to ignore one of the values?
7. Flush CATCH-ALL, UNWIND-ALL NO! Otherwise there is no way to escape
the predefined error semantics. These
provide the essential gross hook that
allows implementation of whatever variant
is necessary. Example: The oly kind of
CATCH Interlisp HAS is effectively
CATCH-ALL
8. DEFMACRO destructuring. Yes.
9. PROCLAIM No, if it is really unnecessary.
10. SIMPLE-VECTOR holds any object I suppose.
Do I hear a proposal for
"SIMPLE SIMPLE VECTORS"?
11. FILL-POINTER Yes.
12. :NAMED in MAKE-ARRAY, MAKE-VECTOR Yes. Element 0 holds the name.
13. *READ-BASE* Yes.
14. SUB-READ, SUB-R-D-L No opinion
15. *PRINfoo* => *PRINT-foo* Yes.
16. ~E,~F,~G like in Fortran Yes.
17. Flush MAXPREFIX,MAXSUFFIX Yes.
18. | : interaction No.
19. ~:A vs NIL vs () Yes.
20. APROPOS, PPRINT return NIL Ok. Rather than a separate family to
specify type of results,
I'd prefer an optional argument to specify
what to do. I usually use
NIL->PRINT
T-> return list
otherwise (APPLY* X --) and
return list of non-nil results
21. *features* are keywords No opinion.
-------
∂31-May-83 1248 BENSON@SPA-NIMBUS Memorial Day Ballot
Received: from SU-DSN by SU-AI with PUP; 31-May-83 12:47 PDT
Received: From MIT-XX by SU-DSN.ARPA; Tue May 31 12:36:57 1983
Date: Tuesday, 31 May 1983, 12:35-PDT
From: BENSON at SPA-NIMBUS
Subject: Memorial Day Ballot
To: Fahlman at CMU-CS-C, common-lisp at su-ai
In-reply-to: The message of 29 May 83 23:18-PDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
1. Yes.
2. Yes.
3. This needs some better justification. It doesn't appear to be useful
in portable code. Are the things returned by these functions
integers?
4. Yes.
5. Yes. Be very careful in explaining this in the manual; it is tricky.
6. No. NIL already has too much attached to it. A decent compiler will
detect variables which are set but not used. It's not important
enough to add another "keyword" usage to NIL.
7. Yes.
8. Yes, with a style hint in the manual that mixing & keywords and
destructuring is poor form. I would like to see a way to use
DEFMACRO-style list groveling (both kinds) in places other than
DEFMACRO. I recently wanted to use it in an assembler, for defining
macros. DLET and/or DESETQ would be very useful.
9. Yes.
10. Yes.
11. Yes.
12. Yes, approximately. Remember, the NAME of the vector is the TYPE of
the DEFSTRUCT (not to be confused with the element type), the thing
returned by TYPE-OF. :NAMED is really the wrong name for this
option. This would in fact be the only place where objects of a new
user-defined type can be created. Perhaps it should be called
:TYPE-OF, although that might cause some confusion with
:ELEMENT-TYPE.
13. Yes, call it *READ-BASE*.
14. No. I don't think the user needs to be concerned with whether a
call to READ is at top level or not, since READ has to use a
special variable to keep track of its state. READ can look at that
variable to see if it is being called recursively; if so, then it
would do SUB-READ. This global state will still be needed, even if
SUB-READ is defined. The only way to avoid it would be to add a third
READER-STATE argument to read macros, which would have to be passed
to recursive READs or SUB-READs. Notice that the example given
under READ-DELIMITED-LIST now has no way of knowing whether to call
READ-DELIMITED-LIST or SUB-READ-DELIMITED-LIST. Rather than adding
this hair, let's leave it up to the system to tell whether it's
being called recursively. A side issue: are dots allowed in
READ-DELIMITED-LIST? I would say no; the manual should specify
either way.
15. Yes.
16. Yes.
17. Yes.
18. Yes. I can't understand why anyone would think it was hard in the
first place.
19. Yes.
20. Yes, but make it T instead. (NIL is so negative!)
21. Put them in the GLOBAL (excuse me, LISP) package, instead of
KEYWORD. Otherwise, users will be typing #+:FOO. Actually, there's
no need to specify. One ought to be able to push any symbol onto
*FEATURES*. The object after #+ and #- should be read just like any
other. Remember, it can be a list, too.
∂31-May-83 1340 @MIT-MC:DLW%SCRC-TENEX%MIT-MC@SU-DSN Re: *prindepth* and *prinlength* versus *prinarray*
Received: from MIT-MC by SU-AI with TCP/SMTP; 31 May 83 13:40:27 PDT
Received: from SCRC-BORZOI by SCRC-TENEX with CHAOS; Tue 31-May-83 16:26:49-EDT
Date: Tuesday, 31 May 1983, 16:26-EDT
From: Daniel L. Weinreb <DLW%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Re: *prindepth* and *prinlength* versus *prinarray*
To: Guy.Steele%CMU-CS-A@SU-DSN
Cc: common-lisp@SU-AI
In-reply-to: The message of 30 May 83 15:42-EDT from Guy.Steele at CMU-CS-A
Date: 30 May 1983 1542-EDT (Monday)
From: Guy.Steele@CMU-CS-A
Page 241 of the Laser manual, under "vectors" and "arrays",
specifically states that printing of vectors and arrays is
affected by *prinlevel* and *prinlength*. Should I put cross-references
to this fact elsewhere?
Quite right, sorry about that. But, yes, it would be nice if it were
mentioned on p 242 in the description of *prinlevel* and *prinlength*
that arrays and vectors are affected. Thanks.
∂31-May-83 1358 BENSON@SPA-NIMBUS Fahlman's latest package printing proposal
Received: from SU-DSN by SU-AI with PUP; 31-May-83 13:58 PDT
Received: From MIT-XX by SU-DSN.ARPA; Tue May 31 13:44:45 1983
Date: Tuesday, 31 May 1983, 13:40-PDT
From: BENSON at SPA-NIMBUS
Subject: Fahlman's latest package printing proposal
To: Common-Lisp at SAIL
Bravo! I knew it wasn't as hard as everyone thought. If we just accept
the fact that packages really are a lot like symbols, everything works
out OK. Now then, suppose we want to change the namespace of packages.
Just bind *PACKAGE-OBARRAY* to :-) !
--Eric
∂31-May-83 1843 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN Memorial Day Ballot: comments on other people's entries
Received: from MIT-MC by SU-AI with TCP/SMTP; 31 May 83 18:42:05 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Tue 31-May-83 21:41:56-EDT
Date: Tuesday, 31 May 1983, 21:40-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Memorial Day Ballot: comments on other people's entries
To: common-lisp@su-ai
In-reply-to: The message of 31 May 83 15:35-EDT from BENSON at SPA-NIMBUS,
The message of 31 May 83 15:01-EDT from Dave Dyer <DDYER at USC-ISIB>,
The message of 31 May 83 05:35-EDT from JONL.PA at PARC-MAXC.ARPA
Date: Tuesday, 31 May 1983, 12:35-PDT
From: BENSON at SPA-NIMBUS
6. No. NIL already has too much attached to it. A decent compiler will
detect variables which are set but not used. It's not important
enough to add another "keyword" usage to NIL.
The issue here is the difference between (MULTIPLE-VALUE (NIL X) (FOO))
and (LET (TEM) (MULTIPLE-VALUE (TEM X) (FOO))). In other words it's not
an attempt to get increased efficiency, but an attempt to increase clarity
by avoiding the need to introduce unnecessary "fake" variables. It's not
a big deal but I thought an explanation might be helpful.
14. No. I don't think the user needs to be concerned with whether a
call to READ is at top level or not, since READ has to use a
special variable to keep track of its state.
The issue is how do you know when to re-bind this special variable? What
if a reader macro, while reading from a file, asks for some input from the
terminal for some reason? What if the same reader macro does the same thing
while reading from the terminal? What if the reason it asked for input wasn't
that it was programmed to, but that it got an error? READ can't tell whether
it was called with the intent of being a recursive call or the intent of being
a top-level call, although there are ways it can guess that work a lot of
the time.
21. Put them in the GLOBAL (excuse me, LISP) package, instead of
KEYWORD. Otherwise, users will be typing #+:FOO.
Of course if the things in *FEATURES* are required to be keywords then
the #+ and #- macros will read in the keyword package or use string-equal or
otherwise arrange for you not to have to type a colon every time.
Actually, there's
no need to specify. One ought to be able to push any symbol onto
*FEATURES*. The object after #+ and #- should be read just like any
other. Remember, it can be a list, too.
This is a reasonable position. In other words, MACSYMA:INTEGRATION and
CIVIL-RIGHTS:INTEGRATION could be two different features from two different
packages, that you might want to test for separately. Saying that features should
be keywords, i.e. that packages lead to too much complexity here, is a reasonable
position, also. The Lisp machine does the latter currently, but that doesn't
mean much. I'm still neutral. But I'm not sure everyone has seen the
point of both sides.
Date: 31 May 1983 1201-PDT
From: Dave Dyer <DDYER@USC-ISIB>
7. Flush CATCH-ALL, UNWIND-ALL NO! Otherwise there is no way to escape
the predefined error semantics. These
provide the essential gross hook that
allows implementation of whatever variant
is necessary. Example: The oly kind of
CATCH Interlisp HAS is effectively
CATCH-ALL
Conditions are not throws. I think Fahlman sent a message in the past few days
that explained this pretty well. I'll be proposing a condition system for Common
Lisp in a few weeks (which could stretch into months, of course).
20. APROPOS, PPRINT return NIL Ok. Rather than a separate family to
specify type of results,
I'd prefer an optional argument to specify
what to do. I usually use
NIL->PRINT
T-> return list
otherwise (APPLY* X --) and
return list of non-nil results
This seems like a good idea, at least for APROPOS. Better than
introducing a new function. Both APROPOS and PPRINT already take an
optional argument, so they may need to be converted to keywords. The
default should be to print out and return nothing.
Date: 31 MAY 83 02:35 PDT
From: JONL.PA@PARC-MAXC.ARPA
Why "but ..."
5 - What about functions that don't pass their keylist on; e.g.
MAKE-ARRAY ? Is it really true that :allow-other-keys will
have the proposed meaning in *every* keyword-taking function?
Yes. What if someone passes his keylist on -to- MAKE-ARRAY?
Spread Uniformity:
The meaning of a lambda-list for DEFUN, for lambda forms, and
for DEFMACRO ought to be perceptually the same
I am in very strong disagreement with this. Functions and special forms
are fundamentally different. "Destructuring" in the lambda list of a
function refers to taking apart THE VALUE OF AN ARGUMENT AT RUN TIME.
"Destructuring" in the "lambda" list of a macro refers to taking apart
THE SYNTACTIC STRUCTURE OF THE INVOKING FORM AT COMPILE TIME. These are
as different as can be. Beginners have enough trouble understanding
this without our throwing additional roadblocks in their way.
Especially is this matter of uniformity important for auto-documentation.
Wouldn't it be nice if you could write
(DEFUN FOO ((A B) C) ...)
rather than
(DEFUN FOO (L C) (PROG ((A (CAR L)) (B (CADR L))) ...))
so that ?= type of helpers would show you more about the syntax
of input arguments?
What if I wanted to say that L was a list and C was an integer? What
if I wanted to say that the first argument was a date and the second
argument was a string which was the name of someone on the Common Lisp
mailing list?
What a loss if such facility worked for DEFUN definitions, but
not for DEFMACRO definitions (and vice-versa)!
Of course you can always get the auto-documentation to say anything
you like, by using (DECLARE (ARGLIST ...)), at least on the Lisp machine.
∂31-May-83 2032 EAK@MIT-MC Memorial Day Ballot
Received: from MIT-MC by SU-AI with TCP/SMTP; 31 May 83 20:30:29 PDT
Date: 31 May 1983 23:30 EDT
From: Earl A. Killian <EAK @ MIT-MC>
Subject: Memorial Day Ballot
To: Fahlman @ CMU-CS-C
cc: common-lisp @ SU-AI
In-reply-to: Msg of Mon 30 May 1983 02:18 EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
3. [GET-INTERNAL-TIME, GET-REAL-TIME]
Certainly both both forms of time are needed. The whole set
of time functions needs improving. I'll send another message
later.
4. [white page macros expand into implementation-independent code]
I am in favor of this. I am also in favor of adding enough
functionality to Common Lisp to make this possible. I don't
think the language is currently portable enough.
9. [PROCLAIM]
I am strongly in favor of a PROCLAIM function. A PROCLAIM
special form is not useful.
11. [FILL-POINTER]
I am strongly in favor of this.
12. [:NAMED]
How about :NAMED-TYPE or :TYPE-NAME?
13. [*IBASE*]
Yes, but rename it *READ-BASE*.
15. [renaming i/o variables etc.]
Yes.
20. [APROPOS, PPRINT return value]
0 values sounds good to me.
21. [package for features]
I prefer allowing feature variables to be in any package, and
to be read normally.
∂31-May-83 2039 EAK@MIT-MC read top-level discussion
Received: from MIT-MC by SU-AI with TCP/SMTP; 31 May 83 20:39:21 PDT
Date: 31 May 1983 23:37 EDT
From: Earl A. Killian <EAK @ MIT-MC>
Subject: read top-level discussion
To: common-lisp @ SU-AI
Another possibility that I don't really like, but I'll suggest
anyway, is to have a form for the user to specify when to start a
new read top-level. The error handler and special reader hacks
would use this. This could be as simple as binding *READ-LEVEL*
to (+ *READ-LEVEL* 1).
∂31-May-83 2043 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN floating-point format
Received: from MIT-MC by SU-AI with TCP/SMTP; 31 May 83 20:42:56 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Tue 31-May-83 23:42:20-EDT
Date: Tuesday, 31 May 1983, 23:41-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: floating-point format
To: Common-Lisp@SU-AI
I went and read the Fortran-77 standard, so now I understand Guy's
proposal.
This mess consists of several sections, separated by rows of dashes:
Guy's proposal (from the memorial day ballot); a condensed form of
the Fortran FORMAT-statement documentation; my suggestions; and the
documentation for ~$ as its exists now in the Lisp machine (Scribe
commands and all).
----------------
16. Guy proposes the following treatment of floating point in FORMAT:
~w,d,pF
~w,d,x,pE
~w,d,pG
The meanings of the arguments are exactly as for the FORTRAN-77
language as described in chapter 13 of the FORTRAN-77 standard,
with the following exceptions and extensions:
(a) The scale factor p is an explicit parameter, rather than being
established be a separate preceding directive. For ~F, p defaults to 0,
and for ~E and ~G it defaults to 1. (In FORTRAN p always defaults
to 0.)
(b) If w is omitted, then the output is variable-width, and never
produces a field of asterisks; the other parameters are observed,
however. So "~,2F" will always print exactly two digits after the
decimal point, and prints as many as necessary to the left of
the decimal point.
(c) If d is omitted then as many digits are produced as necessary
to preserve the information content of the number, except that if
w is specified then the width constraint it imposes overrides this
consideration. (Thus if both are omitted we get free-format output.)
(d) The format operation formerly called ~G will henceforth be called ~@*.
----------------
From ANSI X3.9 1978 (selected highlights from chapter 13)
SP requires + to be output. SS forbids + to be output. S
restores the default, which gives the processor the option
of outputting or not outputting + in I, F, E, D, and G editing.
With a scale factor p: On output, with E editing, the basic real
constant part of the quantity is multiplied by (expt 10 p) and the
exponent is reduced by p. On F output editing the scale factor effect
is that the externally represented number equals the internally
represented number multiplied by (expt 10 p). On output, with G
editing, the effect of the scale factor is suspended unless the use of E
editing is required.
The processor must not produce a negative signed zero in a
formatted output record.
On output the representation is right-justified in the field.
On output, if the number of characters produced exceeds the field width
or if an exponent exceeds its specified length, the processor will fill
the entire field with asterisks. However the processor must not produce
asterisks if the field width is not exceeded when optional characters
are omitted. Plus sign is not optional when SP is in effect.
F editing: Optional blanks, optional sign, and a string of digits that
contains a decimal point, rounded to d fractional digits. Leading zeros
are not permitted except for an optional zero immediately to the left of
the decimal point if the magnitude is less than one. The optional zero
must appear if there would otherwise be no digits in the output field.
[It says nothing about trailing zeros.]
E editing: ~w,d,x,pE
The form of the output field for a scale factor p of zero is
optional-sign optional-zero decimal-point d-digits exp
where exp is a decimal exponent of one of the following forms:
x unspecified, (abs exponent) <= 99: E plus/minus digit digit
or plus/minus zero digit digit
x unspecified, (< 99 (abs exponent) 1000): plus/minus digit digit digit
x specified, (< (abs exponent) (1- (expt 10 x))): E plus/minus x-digits
The sign in the exponent is required. A plus sign must be used if
the exponent value is zero. x must not be unspecified if the
absolute value of the exponent exceeds 999.
If -d < p <= 0, the output field contains exactly -p leading zeros
and d-(-p) significant digits after the decimal point. If 0<p<d+2,
the output field contains exactly p significant digits to the left
of the decimal point and d-p+1 significant digits to the right of
the decimal point. Other values of p are not permitted.
G editing: ~w,d,x,pG
The method of output depends on the magnitude of the datum:
< 0.1: use E format with same parameters
>= (expt 10 d): use E format with same parameters
>= (expt 10 (1- a))
and < (expt 10 a): ~(w-n),(d-a)F ~n@T
where n = x+2 or 4 if x is unspecified
and (<= 0 a d). Thus if F format is used, d significant digits are
printed, of which d-a are fractional, and the overall field width is the
same, with some spaces on the right.
----------------
I like all four exceptions/extensions in Guy's proposal.
On signs: The @ modifier forces a plus sign to be printed, as in ~D.
Without an @, a plus sign is never printed. In either case a minus sign
is printed if the number is negative. Fortran's prohibition against
negative zero is overruled by the proposed IEEE standard.
On arguments: ~F should not allow a scale factor, since it actually changes
the magnitude of the represented number. (I am amenable to allowing it
anyway, since it's optional and the last argument, if anyone has a use
for it). ~w,d,x,pG (note the added x) because it has to pass this on
to ~E if the number is large or small, and if the number is intermediate
it has to use x to line up the columns.
On exponent markers: should the exponent marker always be E? Always
be the same type-dependent exponent marker that PRINT would use?
Or should the : modifier switch between always using E as the exponent
marker and using the type-dependent exponent markers that PRINT uses?
On optional characters: the exponent marker should never be optional.
The sign and leading zeros in the exponent should not be required.
But there is an issue here of trying to line things up in columns.
How about if x is specified then the exponent occupies exactly
x+2 columns, consisting of the E (or other marker), a required sign,
and x digits with leading zeros, whereas if x is unspecified then the
exponent consists of an E (or other marker) followed by a free-format
integer.
On trailing zeros: if d is specified, trailing zeros are printed. If
d is unspecified, trailing zeros are suppressed, except that at least
one digit is printed to the right of the decimal point.
On field overflow: we aren't dealing with 80-column cards here, and
I don't think asterisk fill is ever appropriate. I'd rather see
Common Lisp specify either:
(1) If a number doesn't fit in a field then it is printed in
as wide a field as required to represent it. If a number
printed in F format is too large, E format may be used.
or (2) If a number doesn't fit in a field then the results are
whatever the implementation finds easiest or most tasteful.
On G format: the essential features of G format as compared with F
format are that small numbers are represented exponentially, rather
than underflowing to zero, and that when no exponent is printed blank
space is left where the exponent would be so that the numbers line up
(I suggest we do this only if x is specified).
On type errors: if any of these format operators see a rational
number, they float it and proceed. If any of these format operators
see a non-number, they output it in ~wA format, with *BASE* decimal.
I don't know what is best for complex numbers here.
----------------
The following is the documentation for ~$ as it currently exists.
@subsection(~$ @L[format] directive for floating point)
@L[~$] is a previously undocumented @L[format] directive for floating
point values.
@IndexEntry[Entry={~$},Key={$},Number]
@Index[~$]
@Index[floating point values]
@IndexEntry[Entry/{@L[format] directive},Key/{format directive},Number]
The format for using it follows:
@display{@L[~@i[rdig],@i[ldig],@i[field],@i[padchar]$]}
It expects a flonum argument. The modifiers for @L[~$] are all
optional.
@begin(desplay)
@I[rdig]@\The number of digits after the decimal point. The
default is 2.
@I[ldig]@\The minimum number of digits before the decimal point. The
default is 1. It pads on the left with leading zeros.
@I[field]@\The full width of the field to print in. The default is the
number of characters in the output. The field is padded
to the left with @I[padchar] if necessary.
@I[padchar]@\The character for padding the field if the field is wider
than the number. The default is @L[#\space].
@i[:]@\The sign character is to be at the
beginning of the field, before the padding, rather than just to the left
of the number.
@i[@@]@\The number must always appear signed.
@end(desplay)
@verbatim[@OK[]@~
(format t "~&Pi is ~$" (atan 0 -1)) =>
Pi is 3.14
(format t "~&Pi is ~8$" (atan 0 -1)) =>
Pi is 3.14159265
(format t "~&Pi is ~8,2@@:$" (atan 0 -1)) =>
Pi is +03.14159265
(format t "~&Pi is ~8,2,20$" (atan 0 -1)) =>
Pi is 03.14159265
(format t "~&Pi is ~8,,20,'x@@$" (atan 0 -1)) =>
Pi is xxxxxxxxx+3.14159265
]
It uses free format (@L[~@@A]) for very large values of the argument.
@Index[@L{~@@A}]
∂31-May-83 2121 @MIT-MC:BENSON%SPA-NIMBUS%MIT-MC@SU-DSN Memorial Day Ballot: comments on other people's entries
Received: from MIT-MC by SU-AI with TCP/SMTP; 31 May 83 21:20:11 PDT
Received: from SPA-NIMBUS by SCRC-TENEX with CHAOS; Wed 1-Jun-83 00:21:45-EDT
Date: Tuesday, 31 May 1983, 21:20-PDT
From: BENSON%SPA-NIMBUS%MIT-MC@SU-DSN
Subject: Memorial Day Ballot: comments on other people's entries
To: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>, Common-Lisp@SU-AI
In-reply-to: The message of 31 May 83 18:40-PDT from David A. Moon <Moon%SCRC-TENEX%MIT-MC at SU-DSN>
14. No. I don't think the user needs to be concerned with whether a
call to READ is at top level or not, since READ has to use a
special variable to keep track of its state.
The issue is how do you know when to re-bind this special variable? What
if a reader macro, while reading from a file, asks for some input from the
terminal for some reason? What if the same reader macro does the same thing
while reading from the terminal? What if the reason it asked for input wasn't
that it was programmed to, but that it got an error? READ can't tell whether
it was called with the intent of being a recursive call or the intent of being
a top-level call, although there are ways it can guess that work a lot of
the time.
I guess I have to go along with this. The solution proposed in the
ballot still isn't good enough though, because reader macros have to
know whether they're being called at the top level or not so that they
in turn will know whether to call READ or SUB-READ. I would like to
propose the following instead:
Reader macros take three arguments: the input stream, the macro
character, and the reader state. The third argument is an object which
holds the state of the reading process at the point where the macro
character was encountered. READ and READ-PRESERVING-WHITESPACE take an
optional fourth (and READ-DELIMITED-LIST an optional third) READER-STATE
argument. If a reader macro calls any of these three functions it
should supply its third argument as the callee's READER-STATE argument.
In the case of READ and READ-PRESERVING-WHITESPACE, a NIL value for
EOF-ERRORP in this call may be overridden by a non-NIL value supplied by
(or defaulted in) a dynamically enclosing call and encoded in the reader
state object.
This doesn't require any new functions, and it means that the
reader doesn't have to keep any global state. On the other hand, it
does add another data type, READER-STATE, which is similar to
RANDOM-STATE, i.e. at the user level it's just a token that gets passed
around. It also means that READ takes four optional arguments, but
the fourth is only used in very unusual circumstances.
Allowing user hooks into processes like reading, printing and evaluation
(and even macro expansion, as in COMPILER-LET) tends to lead to problems
like these. For example, there are a bunch of special variables which
act as flags to control the behavior of the printer. There is also a
function, WRITE, which takes keyword arguments for these flags.
However, a function given as an argument to the :PRINT-FUNCTION option
of DEFSTRUCT is supposed to observe the values of the variables in its
behavior. Therefore, WRITE must bind all those special variables to the
values supplied for the keywords (which by default of course are the
values of the special variables). I can't wait to see the lambda list
for that one! Luckily that only infringes on the implementor, not the
user, but it is an unexpected consequence of allowing that hook. And as
I look at it, I see that in order for *PRINPRETTY* (make that
*PRINT-PRETTY*) to be useful, the :PRINT-FUNCTION should be supplied
with a "horizontal position" argument, which should also be passed to
recursive calls to the printer. What units, you say? I have discovered
the general solution to this problem, but unfortunately there isn't
enough space in this editor buffer to fully descr
∂31-May-83 2149 GSB@MIT-ML mem. day ballot
Received: from MIT-ML by SU-AI with TCP/SMTP; 31 May 83 21:49:13 PDT
Date: 1 June 1983 00:50 EDT
From: Glenn S. Burke <GSB @ MIT-ML>
Subject: mem. day ballot
To: common-lisp @ SU-AI
1. Eliminate parse-number.
Have parse-integer, as bernie suggested. This will eliminate
all those dumb loops everyone seems to write all the time, and
will also presumably have less overhead than a general read.
2. BLOCK NIL for LOOP
Yes.
3. get-internal-time/get-real-time
Sure, but i find the names (the contrast between them) disconcerting.
It sounds like they are different units. ("internal" sounds like
an internal representation, whereas "real" does not.) I have no
alternate suggestion, and don't care all that much.
4. Eliminate implementation-dependent special-forms in macro-expansion.
I guess i can accept this, although i would prefer to have a
template-driven code-walker so that this would not be necessary.
(As it is, i have many special forms which aren't even defined
in the interpreter; they exist only to get the compiler to do
some fancy things for special low-level code which never runs
interpreted.)
5. :allow-other-keys
OK.
6. NIL in multiple-value[-bind]
Yes.
7. Eliminate CATCH-ALL and UNWIND-ALL.
No opinion, i haven't thought about them or implemented them.
8. defmacro destructuring
The whole thing should be subject to destructuring, including
those positions in &mumbles which are unambiguous variable
positions. I strongly suggest that we standardize on a
primitive to do a destructuring bind in this manner, with syntax
(name pattern value . body). I can't think up a good name, but
it should not be rooted in LET. My experience with having
LET do this type of destructuring is that it is a pain to do
multiple "parallel" destructurings, and also that they are
much much harder to read with those extra parentheses.
9. DECLARE/PROCLAIM.
Sure.
10. simple-vector
Yes.
11. Flush RESET-FILL-POINTER, add FILL-POINTER.
Sure.
12. :named keyword to make-array/make-simple-vector
I will send this out separately. It bothers me and leaves
too many things unspecified.
13. Reintroduce *IBASE*...
Yes, but *READ-BASE*.
14. sub-read
I really don't care. There is not really a problem with defining
functions in pairs; for instance, in NIL, we have
(defun readline (&restv v)
(read-apply ':readline #'readline-raw v))
(defun read (&restv v)
(read-apply ':read #'read-raw v))
where read-raw and readline-raw are the simpler versions.
15. Propose that we rename *PRINfoo* to *PRINT-foo* for all foo...
Yes.
16. floating-point in format...
Probably the right thing to do. I have not thought about it.
17. Eliminate MAXPREFIX and MAXSUFFIX,...
Sure.
18. vertical bars around a symbol following : or #:
We should definitely allow that. For this, or in fact any
pervasiveness attributable to a package prefix, one only needs
to define the "token" as the characters up to and including the
colon. I do not believe that this is hard to implement. As to
whether the package name may be enclosed in vertical bars, or
have funny hacks with case, really don't care, although i do think
that this will be harder.
19. ~:A and ~:S should only affect the printing of NIL given directly
as an argument, not the printing of NILs inside a printed list. This is
because these are for printing an object that is known to be a list, not
for printing data so it can be read compatibly into a N.I.L system.
Yes. I never did notice that this change had been introduced;
certainly this kludge has never been supported in my lisp
implementation. Who is responsible for this N.I.L. system you
mention which necessitates such grotesqueries?
20. APROPOS and PPRINT should return NIL...
I like zero values, but don't particularly care about that or NIL.
21. *features*...
Put them in the keyword package, and ensure that however the
test after #+/#- is read, it works without colons. (Whether
this be interning them there initially, or doing package-independent
comparison to test the features.)
∂31-May-83 2212 Guy.Steele@CMU-CS-A Moon's remarks on ~F,~E,~G,~$
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 31 May 83 22:10:04 PDT
Date: 1 June 1983 0105-EDT (Wednesday)
From: Guy.Steele@CMU-CS-A
To: common-lisp@SU-AI
Subject: Moon's remarks on ~F,~E,~G,~$
First, namy thanks to Dave for typing all that stuff in from
the FORTRAN-77 standard.
Second, I agree with substantially all of his remarks and proposed
modifications and clarifications.
Regarding fields full of asterisks, there is an interesting suggestion
in the appendixes to the IEEE proposed standard: if a number is too big
to fit in an output field, then the line gets broken. The best way
to see this is by example:
(FORMAT T "~%xxxxx~6,3Fzzzzz" 12345.6789)
xxxxx
12345.6789yyyy
The idea is that if N columns are specified and you need N+K columns
to print the number, and the cursor is at absolute column P, then
you do one of two things:
(a) If you want to keep the right-hand end aligned, output a return
and then tab to column P-K; then output the N+K characters.
(b) If you want to keep the left-hand end aligned, or if P-K is negative,
you output the N+K characters, then a return, then tab to column P+N.
The advantage of this is that it is easy to see what happened,
and columns of numbers stay aligned. Indeed, we might want to consider
this strategy for all fixed-width cases in FORMAT.
--Guy
∂31-May-83 2231 FAHLMAN@CMU-CS-C grt optys in data proc
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 31 May 83 22:30:29 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 1 Jun 83 01:30:39 EDT
Date: Wed, 1 Jun 1983 01:30 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Guy.Steele@CMU-CS-A
Cc: common-lisp@SU-AI
Subject: grt optys in data proc
In-reply-to: Msg of 1 Jun 1983 0105-EDT () from Guy.Steele at CMU-CS-A
The suggestion that you break the line if a number doesn't fit is too
ugly for words and would be a beast to implement. Anything but that --
back up and overstrike, maybe, for as many passes as it takes. That'll
teach the bloody user to overflow... Seriously, this is going too far.
-- Scott
∂01-Jun-83 0036 GSB@MIT-ML defstruct, and the :named option
Received: from MIT-ML by SU-AI with TCP/SMTP; 1 Jun 83 00:34:27 PDT
Date: 1 June 1983 03:35 EDT
From: Glenn S. Burke <GSB @ MIT-ML>
Subject: defstruct, and the :named option
To: common-lisp @ SU-AI
I have developed the impression that the issue concerning the :named
option to make-array is misguided. The object is to be able to have
defstruct produce implementation-independent code for the important
default case where the structure is typed. To specify that this is
necessarily within the domain of arrays is needlessly constraining.
There are three basic functions needed to define a typed structure.
One must define the type, create a structure, and reference the
structure. The type definition may be done with define-structure:
(define-structure <name> <size> [<included-structure-type>]).
This is a macro, which expands into whatever is needed by the
implementation to actually define <name> so that it may be used as a
type specifier, and for its use with make-structure. The "arguments"
are not evaluated. For instance, the astronaut defstruct in the Laser
edition would produce
(define-structure astronaut <size> person).
(make-structure <name> <size>)
creates an empty (uninitialized?) structure for <name>. Perhaps
<size> is not really needed here, but would save looking up <name> in
implementations where no other information is needed.
(structure-ref <structure> <index>)
returns the <index>th slot of <structure>, and works with setf. The
indexing is zero origined. Obviously the compiler can increment the
index if it is a compile-time constant and that is necessary for the
implementation. Checking for such things as :read-only, and hacking
with types (in whatever way), are done by defstruct before the
structure-ref stage is reached.
----------------------------------------------------------------
Additional changes/documentation modifications:
The :named vector type should be specified as not necessarily being
the same as the normal typed structure type, and thus probably not
distinguishable with typep. It may not be different, however,
depending on the implementation!
The predicate defined by the :predicate option should be documented as
being only a heuristic unless the structure is defined in the default
manner. (Should there be a name for this default :type? How about
:typed? :typed-structure? Just :structure?)
The vector type should NOT be :named by default.
The :unnamed option should be eliminated. It only makes sense for the
explicitly specified types (list and vector), which are not named by
default. (Additionally, if the vector has an element-type specified,
it may not, in fact probably will not, be possible to make the vector
be :named. The documentation should point this out, if not make
:named illegal for all but (vector t).)
:initial-offset ??? Presumably this is more reasonable than ever if
we have structure-ref. It might be a good idea to define the order in
which defstruct allocates slots for linear structures (which all of
the Common-Lisp ones are, since there is no :type :tree).
----------------------------------------------------------------
There are a couple alternatives for make-structure which might want to
be considered. For instance, it may be reasonable for make-structure
to be given a template structure to initialize the created structure
to. That way, constant slot initializations will have been done at
structure creation type. This is beneficial in implementations where
data creation needs for some reason or another to initialize the
contents to something. We use this in NIL for flavor instance
initialization now; it speeds things up measurably. If this kind of
thing is added, then possibly the size and/or name might not need to
be given to make-structure. My feeling, however, is that the cleanest
and safest interface would be for a template to be an optional third
argument to make-structure, and be of type (simple-vector t).
Another possibility is for make-structure to take an &rest argument
which specifies the slot initializations, in order. This would have
the advantage of not forcing defstruct to produce a string of setfs to
do the initializations.
∂01-Jun-83 0719 FAHLMAN@CMU-CS-C defstruct, and the :named option
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 1 Jun 83 07:17:32 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 1 Jun 83 10:17:43 EDT
Date: Wed, 1 Jun 1983 10:17 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Glenn S. Burke <GSB@MIT-ML>
Cc: common-lisp@SU-AI
Subject: defstruct, and the :named option
In-reply-to: Msg of 1 Jun 1983 03:35 EDT from Glenn S. Burke <GSB at MIT-ML>
The solution you propose for the :named problem looks to me like the old
"cycle of reincarnation": the "primitives" grow more and more hair,
until pretty soon someone decides that it would be nice to have a
portable implementation of them, if only someone would define the right
primitives. If we're going to put in all the stuff you suggest, we
might as well just say that DEFSTRUCT itself is a primitive that works
by implementation-dependent magic and let it go at that. The original
pont was to add one tiny operation so that all the rest of DEFSTRUCT
could be portable.
-- Scott
∂01-Jun-83 1258 KMP@MIT-MC
Received: from MIT-MC by SU-AI with TCP/SMTP; 1 Jun 83 12:58:27 PDT
Date: 1 June 1983 14:23 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
To: Common-Lisp @ SU-AI
Having watched the mail coming in, I wish to change my vote on 21 (#+/#-)
to concur with EAK and Benson, that features should be allowed to be any
symbol and packageness should matter. Certain important initial features
might want to be global (LISP), I'm not sure about this. But in thinking
back over the problems that happened in the past where several string packages
existed, it seems to me the only reasonable way to handle this is to allow
everyone to name their feature "STRING" and allow the package prefix to have
meaning. This is considerably better than resorting to subtle differences
in keyword name such as were eventually tried (STRING, STRINGS, ...) and
hoping that no one else tried the same trick you tried. The problem is
nearly the same as the gensym problem in that you want unique IDs for features,
and it is worse than the gensym problem in that you want to be able to type
the names in. This is one case where, in spite of my dislike for packages
in general, I think they have a place.
∂01-Jun-83 1352 KMP@MIT-MC (MULTIPLE-VALUE (NIL ...) ...)
Received: from MIT-MC by SU-AI with TCP/SMTP; 1 Jun 83 13:51:48 PDT
Date: 1 June 1983 16:53 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
Subject: (MULTIPLE-VALUE (NIL ...) ...)
To: Common-Lisp @ SU-AI
By the way, I have carefully watched my code over the last year and in easily
three quarters of the cases where I wanted to ignore arguments, it was because
I in fact only wanted one value back. In Moon's example, I agree that
(LET (TEM) (MULTIPLE-VALUE (NIL TEM) ...) ...)
is not as nice as
(MULTIPLE-VALUE-BIND (NIL TEM) ... ...)
but I would prefer
(LET ((TEM (NTH-VALUE 2 ...))) ...)
myself.
On the other hand, I think the point of Benson's note was to point out that
the compiler should be able to handle
(MULTIPLE-VALUE-BIND (IGNORE TEM) ... ...)
if IGNORE isn't used, without needing to make something special about NIL.
I am sympathetic to such an argument.
In any case, in addition to (not in place of) anything that is decided along
these lines, what would people think about adding NTH-VALUE to the list of
available primitives? From my experience, it's frequently just the right thing.
--kmp
∂01-Jun-83 1413 Walter.VanRoggen@CMU-CS-A Memorial Day Ballot
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 1 Jun 83 14:10:34 PDT
Date: 1 June 1983 1546-EDT (Wednesday)
From: Walter van Roggen <Walter.VanRoggen@CMU-CS-A> (C410WV50)
To: Fahlman@cmu-cs-c
Subject: Memorial Day Ballot
CC: common-lisp@su-ai
Message-Id: <01Jun83.154637.WV50@CMU-CS-A>
[1] ok
[2] ok
[3] yes. GET-INTERNAL-TIME and GET-REAL-TIME might return different
values even for a personal machine. Return values should be in
units of INTERNAL-TIME-UNITS-PER-SECOND. Some implementations
might want to return multiple-values to separate out GC time.
[4] ok
[5] yes
[6] maybe: why not in all lambda lists?
[7] no and yes. I don't know why people have been talking about using
CATCH-ALL to handle errors in particular. It seems the natural way
to detect, and perhaps intercept, throws of any kind, particularly
unknown ones. Say you have a large program with many different
"top-levels", and corresponding different interrupt characters (like
↑G). At some level, you might want to restrict which levels one might
pop up to. You need to know what the throw tag is. But given both
UNWIND-PROTECT and CATCH-ALL, UNWIND-ALL doesn't seem so useful.
Also, is CATCH-ALL so much harder to implement than UNWIND-PROTECT?
[8] no. I presume you don't really mean that DEFMACRO is used by users
to define special forms. Lisp implementors' use of DEFMACRO for special
forms doesn't have to be nice looking. Furthermore, list destructuring
in parameter lists is visually confusing and conceptually confusing
because of the difference with normal lambda lists. I often find
it convenient to convert from DEFUN to DEFMACRO.
On the other hand, destructuring can be very convenient. This is a
separate issue, but I would like to see a more general destructuring
LET as a facility in its own right, with which it would be easy to
implement destructuring defmacros. This would apply not only to lists,
but to structures also. One annoyance I've noticed with lots of
defstructs is that it's tedious to have to write all those (foo-slot x)
forms. It would be nice to have something equivalent to the PASCAL WITH.
SETF would have to be smarter, though.
[9] ok
[10] ok. It's good to get rid of SGVREF.
Looking at the array chapter I thought there was no way to reference
a non-simple vector while observing the fill-pointer, since AREF doesn't
and things like CHAR are defined in terms of AREF. But I presume ELT
does; there need to be cross-references both ways. So implementations
have to duplicate the array referencing mechanism for vectors (e.g.,
for declared strings). It would also be good to state for THE, examples
like (THE (VECTOR CHARACTER n) (THE (SIMPLE-ARRAY STRING-CHAR n) foo)).
I presume also that MAKE-SIMPLE-VECTOR no longer takes an :ELEMENT-TYPE
keyword, and therefore VECTOR changes.
My main complaint is that we are encouraging a proliferation of accessing
types. Much as there is no VREF, let's get rid of CHAR and BIT. Since
we think there will be much use of SVREF, keep SCHAR and SBIT. Finally,
we should consider renaming those three without the "S".
[11] yes
[12] ok. But can't DEFSTRUCT always assume the first slot is used if named?
[13] yes, *READ-BASE*. How about changing *PRINT-RADIX* to mean "whenever
*BASE* isn't 10." Perhaps also then change its default value to T.
[14] ok with keywords
[15] yes
[16] I don't even want to think about it.
[17] yes
[18] ok. why can't package prefixes be treated exactly like symbols,
except that they aren't interned? #\: terminates unless quoted.
Package names are backslashified or ||'d on printing. So |aBC|:|Foo|
or |:|:|:| or |temp|#:G0001
[19] ok
[20] no. TIME, DESCRIBE, APROPOS, and ROOM are all similar; they all are
most commonly used interactively at top-level. I suggest an optional
keyword arg that specifies which stream to output to, just like
FORMAT. Since these functions will be so implementation-dependent,
we shouldn't restrict what they do nor what they return.
As a general rule, 0 values sounds reasonable when just printing.
Implementations should be able to add their own keyword args, and
return whatever lists (or ?) appropriate. For APROPOS, you might be
interested in defined symbols only; APROPOS-LIST is too specific
(and it's easy to write anyway). APROPOS, might want to capitalize
the string first, also.
[21] no, you may want to check for symbols in particular packages.
---Walter
∂01-Jun-83 1456 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN defstruct, and the :named option
Received: from MIT-MC by SU-AI with TCP/SMTP; 1 Jun 83 14:46:36 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Wed 1-Jun-83 17:29:02-EDT
Date: Wednesday, 1 June 1983, 17:22-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: defstruct, and the :named option
To: common-lisp@su-ai
In-reply-to: The message of 1 Jun 83 10:17-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Glenn has a point, which is that the Common Lisp language has no business assuming
that the default defstruct type is a vector. Hence my suggestion that a :named
keyword be added to make-array and make-vector was a bad suggestion and I withdraw it.
We can do one of two things: put in the new "abstract" structure creation primitives
GSB suggested, which in implementations that use vectors for structures are macros
that turn into the usual vector primitives (and those implementations do have a :named
option in their make-vector and make-array functions, presumably). Or we can give up
on having defstruct be a portable program and require every implementation to write
their own (perhaps by munging a copy of someone else's). It's an issue of extra
language complexity versus maintenance headaches.
∂01-Jun-83 1558 FAHLMAN@CMU-CS-C (MULTIPLE-VALUE (NIL ...) ...)
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 1 Jun 83 15:54:36 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 1 Jun 83 18:54:44 EDT
Date: Wed, 1 Jun 1983 18:54 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Kent M. Pitman <KMP@MIT-MC>
Cc: Common-Lisp@SU-AI
Subject: (MULTIPLE-VALUE (NIL ...) ...)
In-reply-to: Msg of 1 Jun 1983 16:53 EDT from Kent M. Pitman <KMP at MIT-MC>
I question the general usefulness KMP's proposed NTH-VALUE form. In
most cases where the user wants just one value, he wants the first one.
If he wants some interior value, he is likely to be using
MULTIPLE-VALUE-BIND instead of MULTIPLE-VALUE. So it seems to me that
there would be very few places where NTH-VALUE would be useful.
-- Scott
∂01-Jun-83 1602 GSB@MIT-ML randomness
Received: from MIT-ML by SU-AI with TCP/SMTP; 1 Jun 83 16:01:27 PDT
Date: 1 June 1983 19:02 EDT
From: Glenn S. Burke <GSB @ MIT-ML>
Subject: randomness
To: Fahlman @ CMU-CS-C
cc: common-lisp @ SU-AI
(Yes, really, randomness. Nothing to do with the ballot.)
There should be a clearly defined way in which one can create a
random-state which has a "consistent" state; that is, from which one
will get the same sequence of random numbers. Saving a copy of
*random-state* is not sufficient, because then one has to depend on
being able to get the same one in what might be different debugging
sessions.
One possibility is to allow make-random-state to be given a seed (an
integer? integer or float?), and having it defined to use that seed in
such a way that the random-state will always be the same for the given
implementation when given the same seed.
∂01-Jun-83 1657 @MIT-MC:HIC%SCRC-TENEX%MIT-MC@SU-DSN Re: defstruct, and the :named option
Received: from MIT-MC by SU-AI with TCP/SMTP; 1 Jun 83 16:55:32 PDT
Date: 1 Jun 1983 1954-EDT
From: Howard I. Cannon <HIC%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Re: defstruct, and the :named option
To: Moon%SCRC-TENEX%MIT-MC@SU-DSN
cc: common-lisp@SU-AI
In-Reply-To: The message of Wednesday, 1 June 1983, 17:22-EDT from David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
In regards to non-portable vs. portable programs like Defstruct, it seems to me
that it's not an all or nothing decision. When thinking about the Flavor stuff,
I came to the conclusion that what I'd supply would be a piece of portable
code that implemented most of the Flavor system, and a set of well defined and
documented functions that were machine dependent, and had to be reproduced
for the particular machine/implementation. I guess what I'm saying is that the
abstract structure creation primitives don't necessarily have to be in the
language definition -- they can be in the Defstruct package definition. I suspect
that there will be many "portable" programs that use this approach.
-------
∂01-Jun-83 1751 @SU-SCORE.ARPA:JonL.pa@PARC-MAXC.ARPA Spread Uniformity and Auto-Doc -- your comments
Received: from SU-SCORE by SU-AI with TCP/SMTP; 1 Jun 83 17:48:46 PDT
Received: from PARC-MAXC.ARPA by SU-SCORE.ARPA with TCP; Wed 1 Jun 83 17:52:19-PDT
Date: Wed, 1 Jun 83 17:51 PDT
From: JonL.pa@PARC-MAXC.ARPA
Subject: Spread Uniformity and Auto-Doc -- your comments
To: Moon%scrc-tenex@MC.ARPA
cc: Common-Lisp%SU-AI@SCORE.ARPA
Dave, I'm not sure we're talking about the same issues -- I've marked a ! in
front of the lines with your replies to my comments.
re: Spread Uniformity
Date: Tue, 31 May 83 21:40 EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN.ARPA>
Subject: Memorial Day Ballot: comments on other people's entries
To: common-lisp@su-ai.ARPA
. . .
Spread Uniformity:
The meaning of a lambda-list for DEFUN, for lambda forms, and
for DEFMACRO ought to be perceptually the same . . .
! I am in very strong disagreement with this. Functions and special forms
! are fundamentally different. "Destructuring" in the lambda list of a
! function refers to taking apart THE VALUE OF AN ARGUMENT AT RUN
! TIME. "Destructuring" in the "lambda" list of a macro refers to taking apart
! THE SYNTACTIC STRUCTURE OF THE INVOKING FORM AT COMPILE
! TIME. These are as different as can be.
WHAT? "COMPILE TIME"?? You mean I can't run my macros interpretively
at "run time" in CommonLisp? Or, have you just overlooked that the
macro expansion function has its own place in the sun, its own "run time".
Seriously, though, the relevant issue is separating out the syntax of function
definition from the reason why, or goal towards which that function is
defined. It should come as no surprise that there are functions which do
S-expression to S-expression translations ** and which serve the dual purpose **
of being the support for a named macro in one context, and merely a function
called by some automated code analyzers in another context. This situation arises
frequently when one writes a translator which "compiles" from a Lisp-like
language into some standard-subset Lisp. DEFMACRO is merely a succinct way
of saying "assign this function to be the code-expander for that macro".
re: Auto-Documentation
. . .
Especially is this matter of uniformity [for arg-list destructuring]
important for auto-documentation. Wouldn't it be nice if you could write
(DEFUN FOO ((A B) C) ...)
rather than
(DEFUN FOO (L C) (PROG ((A (CAR L)) (B (CADR L))) ...))
so that ?= type of helpers would show you more about the syntax
of input arguments?
. . .
What a loss if such facility worked for DEFUN definitions, but
not for DEFMACRO definitions (and vice-versa)!
! Of course you can always get the auto-documentation to say anything
! you like, by using (DECLARE (ARGLIST ...)), at least on the Lisp machine.
No doubt this declaration was inspired by the Interlisp ARGLIST function. But
surely you don't mean to imply that installing special information "by hand"
is "automatic" documentation. Or, maybe you do. The Interlisp function
SMARTARGLIST goes out and consults an on-line manual, which is fine
documentation for the system functions at least (or rather, those system
functions for which someone bothered to write manual documentation).
∂01-Jun-83 1818 HEDRICK@RUTGERS.ARPA our votes in the Memorial Day Ballot
Received: from RUTGERS by SU-AI with TCP/SMTP; 1 Jun 83 18:14:54 PDT
Date: 1 Jun 83 21:17:40 EDT
From: Dir LCSR Comp Facility <HEDRICK@RUTGERS.ARPA>
Subject: our votes in the Memorial Day Ballot
To: fahlman@CMU-CS-C.ARPA
cc: common-lisp@SU-AI.ARPA
1. Yes, delete PARSE-NUMBER. We like the idea of a simpler PARSE-INTEGER.
2. Yes, LOOP should create BLOCK NIL
3. Yes, we favor GET-INTERNAL-TIME and GET-REAL-TIME, however:
- we would like better names, e.g. GET-RUN-TIME and GET-CLOCK-TIME
- we would like a function or read-only variable that gives the number
of ticks per second
4. Yes, we agree that macros should not expand to undocumented special forms.
5. We abstain on :ALLOW-OTHER-KEYS
6. No, we do not want to complicate MULTIPLE-VALUES. (Actually, we would
strongly favor simplifying it by removal.)
7. Yes, we agree to eliminate CATCH-ALL and UNWIND-ALL. If Moon can't
think of any use for them, we are sure we won't be able to.
8. Yes, we agree to adding destructuring to DEFMACRO. We are persuaded
that documentation and other program-understanding functions could
be helped if they can easily see what is going on in the macro.
9. Yes, restrict DECLARE and add PROCLAIM. (Alternatively, we would be
happy to forget PROCLAIM. Make DECLARE typed at top level act
like PROCLAIM.)
10. Yes, restrict SIMPLE-VECTOR.
11. Yes, use (FILL-POINTER) and (SETF (FILL-POINTER...
12. No, we oppose named vectors. They appear to be a half-baked compromise
that we think you will regret. I am sympathetic with the idea of
defining how DEFSTRUCT is to be implemented. We think that you
should either make these a full type, or a documented programming
convention. Named vectors seem to be half-way in between and to
share the disadvantages of both.
13. Yes, put in *READ-BASE*
14. No, we oppose SUB-every read function. There has to be a better way.
And not keywords.... If the combined wisdom of this list can't
come up with a better way, then maybe a month from now...
15. Yes, rename *PRINfoo*
16. Yes, do what Guy wants with floating point formats. (I give him my
proxy to make minor adjustments latter if he has better ideas.)
17. Yes, eliminate MAXPREFIX and MAXSUFFIX.
18. We favor Scott's ideas on package names.
19. Yes, ~:A and ~:S should affect only top-level NIL's.
20. We would accept makig APROPOS and PPRINT return NIL, but would prefer
having them return no values.
21. Yes, make features keywords.
-------
∂01-Jun-83 1927 KMP@MIT-MC NTH-VALUE, some examples
Received: from MIT-MC by SU-AI with TCP/SMTP; 1 Jun 83 19:13:33 PDT
Date: 1 June 1983 22:15 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
Subject: NTH-VALUE, some examples
To: Fahlman @ CMU-CS-C
cc: Common-Lisp @ SU-AI
I think the main argument is that it's fine to want to bind values coming
back, but I don't think multiple values will ever have "first class" state
in the language until the set of primitives is rich enough that you aren't
forced to do clumsy things to use them. I currently prefer
(LET ((VSIZE (CADR (MULTIPLE-VALUE-LIST (SEND TERMINAL-IO ':SIZE)))))
...)
to using MULTIPLE-VALUE-BIND for implementing a selector such as this, and
I am very saddened that this conses. I feel that this has the word "cliche"
written all over it.
Style issues aside, this case could be written with MULTIPLE-VALUE-BIND but
the case of
(LET ((X (NTH-VALUE N (FOO)))) ...)
can in fact not be written without consing in any form.
Note further that allowing an NTH-VALUE primitive lends itself to more
portable abstractions. Macros can be written which syntactically appear
to reference a structure, allowing efficient implementation in dialects
supporting multiple values and slightly slower implementations in those
dialects which don't.
A quickie poll of the LispM around now users showed that just under half
(~4) thought it was obvious that there should be an NTH-VALUE
to handle common cases like:
(LET ((VSIZE (NTH-VALUE 1. (SEND TERMINAL-IO ':SIZE)))) ...) ;or :EDGES
(COND ((NTH-VALUE 1. (CATCH-ERROR (EVAL FORM))) ;for effect
...))
About as many (~4) had never wanted such a feature, but these people
admitted not using multiple values much. 1 claimed not to have ever wanted
it but said that it sounded useful, and 2 hit me with arguments about
how people don't want multiple values anyway, they want structures, and
only the compiler should ever know...
∂01-Jun-83 1943 EAK@MIT-MC NTH-VALUE
Received: from MIT-MC by SU-AI with TCP/SMTP; 1 Jun 83 19:40:14 PDT
Date: 1 June 1983 22:42 EDT
From: Earl A. Killian <EAK @ MIT-MC>
Subject: NTH-VALUE
To: common-lisp @ SU-AI
I am in favor of this. I think it will be very very common,
because (NTH-VALUE 2 (FLOOR A B)) is how you would do modular
arithmetic.
∂01-Jun-83 2158 FAHLMAN@CMU-CS-C Non-yucky package names (I think)
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 1 Jun 83 21:51:35 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 2 Jun 83 00:51:29 EDT
Date: Thu, 2 Jun 1983 00:51 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: David A. Moon <Moon%SCRC-TENEX@su-ai>
Cc: Common-Lisp@su-ai
Subject: Non-yucky package names (I think)
In-reply-to: Msg of 2 Jun 1983 00:19-EDT from David A. Moon <Moon at SCRC-TENEX>
Well, the big advantage of my package-name proposal was that it doesn't
create yet another set of case rules. All that the user has to remember
is that package names are treated EXACTLY like symbols with regard to
case and escape conventions. Both your proposals -- forbidding
veritical bars and doing case-insensitive lookup -- have some merit, but
violate this uniformity. I would prefer not to diverge in this way.
-- Scott
∂01-Jun-83 2218 Guy.Steele@CMU-CS-A Re: grt optys in data proc
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 1 Jun 83 22:08:40 PDT
Date: 2 June 1983 0100-EDT (Thursday)
From: Guy.Steele@CMU-CS-A
To: Scott E. Fahlman <Fahlman@CMU-CS-C>
Subject: Re: grt optys in data proc
CC: common-lisp@SU-AI
In-Reply-To: "Scott E. Fahlman's message of 1 Jun 83 00:30-EST"
"Too ugly for words": De gustibus non disputandum est. There is a problem
with what to do if a quantity will not fit in the FORMAT field allotted
to it. Some constraint has to give:
(a) The FORTRAN solution is to sacrifice the requirement of printing the
datum; instead, a field of asterisks is printed.
(b) The current MacLISP/LISP Machine solution is to sacrifice horizontal
alignment; the datum is allotted extra columns, and everything to the
right gets pushed over.
(c) The suggestion from the IEEE standard is to sacrifice vertical
alignment, by pushing everything below the line down, in order to create
room for the too-large datum without misaligning everything else to the
right.
It seems to be simply a matter of which two of the three constraints
seem more important than the third. I don't much care; I just wanted
to offer this unusual alternative. I find that it doesn't look too
bad in practice.
"A beast to implement": I didn't think it was that bad. Given that
you're trying to right-justify some data in a fixed-width field anyway,
you must have calculated the needed width ahead of time anyway in
order to pad on the left. It is just a couple of conditional tests,
that I supplied in my note, to determine what action to take. The success
of the action depends only upon being able to detect the current column
position; i.e., it can win iff a ~T command could win. If a ~T command
could not win, then you just punt this strategy and revert to strategy (b)
above.
I don't much care, but would like to know whether other people find
this idea interesting. Too bad Moon used up the : and @ flags for
something else. (Say! I was going to suggest a third flag character "!"
because ~C needs more than four variants. For ~F, ~E, ~G it could
specify whether you want to preserve vertical and horizontal alignment.
And just think of what an extra flag character could do for ~[ !
~:![ could be an unwind-protect: ~:![aaa~;bbb~] outputs bb even if
a ~↑ happens within aaa. And
here
I
go
off
the
deep
end
!
--Guy
∂01-Jun-83 2251 Guy.Steele@CMU-CS-A Re: randomness
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 1 Jun 83 21:56:06 PDT
Date: 2 June 1983 0048-EDT (Thursday)
From: Guy.Steele@CMU-CS-A
To: Glenn S. Burke <GSB@MIT-ML>
Subject: Re: randomness
CC: common-lisp@SU-AI
In-Reply-To: "Glenn S. Burke's message of 1 Jun 83 18:02-EST"
The description of *random-state* in the Laser edition requires
that it be possible to print out a RANDOM-STATE object and read it
back in "suvvessfully". This wording is not as clear as it should be,
but the intent was that you can use PRINT to squirrel away and
READ to retrieve a RANDOM-STATE that would be good for multiple sessions
of a single implementation. Does this accomplish what you want?
--Guy
∂02-Jun-83 0008 FAHLMAN@CMU-CS-C The envelope please...
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 1 Jun 83 23:44:43 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 2 Jun 83 02:45:01 EDT
Date: Thu, 2 Jun 1983 02:45 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: common-lisp@su-ai
Subject: The envelope please...
Here is my interpretation of the results of the Memorial Day ballot.
A number of new issues have been raised since this went out, so there
will be another small ballot going out tomorrow.
Note that the raw vote-count doesn't decide the issue here. One good
argument pointing out why something is unworkable is stronger than any
number of "OK, I'll go along with the proposal" votes, especially if
those votes came before the argument. On questions of mechanics, people
speaking for an implementation group carry more weight than others. On
questions of taste, the process is pretty democratic, but perhaps
weighted slightly for experience. Again, in matters of taste, a cogent
argument carries extra weight.
The result, then, must be somewhat subjective. My goal here is to come
up with a solution that we all can live with and to do so with a minimum
of futher iteration. If there's some wiggle room left within those
bounds, then I try to find the solution that best satisfies the
aggregate taste of the community.
If any of the decisions made here strikes you as something that you just
cannot live with, let me know right away. But before you complain,
think about the fact that getting the manual completed and out very soon
is extremely important to some of the implementation efforts.
-- Scott
--------------------------------------------------------------------------
1. Flush PARSE-NUMBER: APPROVED. Glenn Burke has proposed a much
simpler PARSE-INTEGER function which does most of what PARSE-NUMBER
would have been used for and which is trivial to implement. This will
be on tomorrow's ballot.
--------------------------------------------------------------------------
2. LOOP makes a BLOCK NIL: APPROVED.
--------------------------------------------------------------------------
3. Split GET-INTERNAL-TIME into two functions, one to get real time and
one to get runtime. This was poorly explained on the original ballot,
and there were some objections by people who clearly had misunderstood
the proposal. Among the rest of the responses, there seemed to be no
opposition to the proposal, but a number of people pointed out that my
proposed names were losers. I'm going to treat the proposal as being
APPROVED unless someone explodes.
To reiterate, these functions are for low-level, fine-grained metering
of perfomance. They need to be quick and do not want to be loaded down
with keywords or other hair. Each returns an integer that is the real
time or run time since some arbitrary starting point. The size of the
tick is implementation-dependent and is indicated by the constant
INTERNAL-TIME-UNITS-PER-SECOND.
The best names I've heard so far are GET-INTERNAL-RUN-TIME and
GET-INTERNAL-REAL-TIME. These are verbose, but that's not too bad since
these are low-level functions that will seldom be typed at the terminal.
The names evoke the familiar concepts of runtime and real time, but also
emphasize the link to the INTERNAL-TIME-UNITS-PER-SECOND constant.
Also, the names are similar in form, which is important for functions so
similar to one another. If anyone comes up with a better pair of names in
the next day or so, those will be used. Otherwise, these names will be
used.
---------------------------------------------------------------------------
4. Built-in macros cannot expand into implementation-dependent special
forms. REJECTED. This is one of the areas where negative comments by
implementors carried extra weight. There was a lot of support for the
view that this restriction, while not impossible, would cause
considerable grief for implementors. There were also many comments that
portable code-walkers just need some sort of mechanism for describing
new special forms.
---------------------------------------------------------------------------
5. The :allow-other-keywords proposal: APPROVED.
---------------------------------------------------------------------------
6. NIL means "ignore this value" in MULTIPLE-VALUE: REJECTED. Basically
a taste issue. There was some sentiment both ways, but more in favor of
not doing this. (My vote has gone negative on this, on the grounds that
MULTIPLE-VALUE will not be used much compared to MULTIPLE-VALUE-BIND. A
little extra convenience in a few cases is not sufficient to justify a
confusing exception.)
---------------------------------------------------------------------------
7. Flush CATCH-ALL and UNWIND-ALL: APPROVED. Nobody came up with a case
in which these were clearly needed (modulo some confusion between THROW
and condition signalling) and a substantial majority favored eliminating
them.
---------------------------------------------------------------------------
8. Let DEFMACRO destructure: APPROVED. A couple of people objected on
the grounds that destructuring can lead to confusing lambda-lists, and a
couple of others suggested that destructuring should be applied to the
lambda-lists of functions as well. (I am violently opposed to the
latter suggestion.) Most people seemed to agree with Moon that
destructuring makes sense in defmacro, since it is used to create macros
that behave like special forms. I take it that the proposal most people
favor is the one that allows destructuring (of lists or dotted lists,
not vectors and other odd items) in any place where a regular lambda-list
accepts a variable.
---------------------------------------------------------------------------
9. Moon's PROCLAIM proposal: APPROVED. A couple of people referred to
an earlier demonstration that the split was not necessary if you were
willing to forego error checking, but most favored the change. Some
people suggested that PROCLAIM should be a function, not a special form.
This will be an item on tomorrow's ballot.
---------------------------------------------------------------------------
10. Moon's Simple-Vector proposal: APPROVED.
---------------------------------------------------------------------------
11. Replace RESET-FILL-POINTER with SETF of FILL-POINTER: APPROVED.
---------------------------------------------------------------------------
12. Add :NAMED to MAKE-ARRAY: REJECTED. Withdrawn by Moon, who proposed
it. A more complex proposal by GSB will appear on tomorrow's ballot.
---------------------------------------------------------------------------
13. *IBASE* to be reincarnated as *READ-BASE*: APPROVED.
---------------------------------------------------------------------------
14. SUB-READ: REJECTED. One or more replacement proposals will appear on
tomorrow's ballot, since the current situation is unworkable.
---------------------------------------------------------------------------
15. *PRINmumble* => *PRINT-MUMBLE*: APPROVED.
---------------------------------------------------------------------------
16. Fortran-type ~E, ~F, ~G: APPROVED. I sense a general willingness to
let Steele and Moon bash out the details on this (as long as
overflowing fields don't go onto the next line).
---------------------------------------------------------------------------
17. Flush MAXPREFIX, MAXSUFFIX, and change the value returned by
MISMATCH :FROM-END. APPROVED.
---------------------------------------------------------------------------
18. Allow vertical bars around qualified symbols: DEFERRED. The
additional proposal to treat both halves of package:symbol the same with
respect to case seems to be agreeable to most people, but I'll put this
and some other suggestions on tomorrow's ballot.
---------------------------------------------------------------------------
19. ~:A and ~:S change the printing of NIL only for the whole argument,
not for sub-forms: APPROVED.
---------------------------------------------------------------------------
20. Do not return the argunet as the value of PPRINT or APROPOS:
APPROVED, but return no value instead of NIL. The choice of NIL was
mine because I am still uncomfortable around functions that refuse to
speak to me, except in the third person, but clearly the rest of you
feel otherwise.
---------------------------------------------------------------------------
21. The symbols on the *FEATURES* should be keywords: REJECTED. People
were generally indifferent to this issue until Benson made explicit the
issue of either having to type #+:foo or fudging #+ to look things up in
odd ways. Since then, sentiment has been running strongly in favor of
allowing any symbol (or indeed any Lisp object, presumably assuming an
EQ test) in this list. Several people (including me) have changed their
earlier votes to this new position. I take this as latter proposal as
being approved, and the original as being rejected.
∂02-Jun-83 0911 @MIT-MC:BSG%SCRC-TENEX%MIT-MC@SU-DSN The envelope please...
Received: from MIT-MC by SU-AI with TCP/SMTP; 2 Jun 83 09:11:22 PDT
Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Thu 2-Jun-83 12:10:51-EDT
Date: Thursday, 2 June 1983, 12:10-EDT
From: Bernard S. Greenberg <BSG%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: The envelope please...
To: Fahlman%CMU-CS-C@SU-DSN, common-lisp@su-ai
In-reply-to: The message of 2 Jun 83 02:45-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: Thu, 2 Jun 1983 02:45 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
--------------------------------------------------------------------------
1. Flush PARSE-NUMBER: APPROVED. Glenn Burke has proposed a much
simpler PARSE-INTEGER function which does most of what PARSE-NUMBER
would have been used for and which is trivial to implement.
Did I miss something? Did Glenn offer a counter-proposal, or is this
a GSB/BSG confusion problem, which has happened before?
∂02-Jun-83 1000 FAHLMAN@CMU-CS-C BSG /= GSB
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 2 Jun 83 09:38:24 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 2 Jun 83 12:38:44 EDT
Date: Thu, 2 Jun 1983 12:38 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: common-lisp@su-ai
Subject: BSG /= GSB
The PARSE-INTEGER proposal was submitted by Bernie Greenberg (BSG),
not by Glenn Burke (GSB), though Glenn sent a message endorsing the
proposal. My apologies to Bernie and Glenn for the confusion.
.lanimret ym htiw gnorw gnihtemos ro aixelsyd eb tsuM
ttocS --
∂02-Jun-83 1351 @USC-ECL,@MIT-MC:BSG%SCRC-TENEX@MIT-MC The dogma killed ASET
Received: from USC-ECL by SU-AI with TCP/SMTP; 2 Jun 83 13:51:25 PDT
Received: from MIT-MC by USC-ECL; Thu 2 Jun 83 13:49:06-PDT
Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Thu 2-Jun-83 16:35:20-EDT
Date: Thursday, 2 June 1983, 16:35-EDT
From: Bernard S. Greenberg <BSG%SCRC-TENEX@MIT-MC>
Subject: The dogma killed ASET
To: common-lisp%su-ai@usc-ecl
While writing some common lisp code today, I was reminded that ASET
was removed because "You should be using SETF". Unfortunately,
what I wanted to do was (apply #'aset value array list-of-subscripts),
a very reasonable thing in a recursive array-processing program,
and I find there is no way to do this in Common Lisp. Opinions?
∂02-Jun-83 1504 @MIT-MC:Moon@SCRC-TENEX NTH-VALUE
Received: from MIT-MC by SU-AI with TCP/SMTP; 2 Jun 83 15:03:56 PDT
Received: from SCRC-EUPHRATES by SCRC-SPANIEL with CHAOS; Wed 1-Jun-83 23:48:03-EDT
Date: Wednesday, 1 June 1983, 23:43-EDT
From: David A. Moon <Moon at SCRC-TENEX>
Subject: NTH-VALUE
To: Earl A. Killian <EAK at MIT-MC>
Cc: common-lisp at SU-AI
In-reply-to: The message of 1 Jun 83 22:42-EDT from Earl A. Killian <EAK at MIT-MC>
Date: 1 June 1983 22:42 EDT
From: Earl A. Killian <EAK @ MIT-MC>
I am in favor of this. I think it will be very very common,
because (NTH-VALUE 2 (FLOOR A B)) is how you would do modular
arithmetic.
I'm not opposed to NTH-VALUE. But allow me to point out that
(NTH-VALUE 2 (FLOOR A B)) is NIL and (NTH-VALUE 1 (FLOOR A B))
is (MOD A B). We are sure not going to have ONE function in
this language that uses one-origin indexing, with everything else
using zero-origin indexing!
∂02-Jun-83 1506 @MIT-MC:Moon@SCRC-TENEX Non-yucky package names (I think)
Received: from MIT-MC by SU-AI with TCP/SMTP; 2 Jun 83 15:05:59 PDT
Received: from SCRC-EUPHRATES by SCRC-SPANIEL with CHAOS; Thu 2-Jun-83 00:25:02-EDT
Date: Thursday, 2 June 1983, 00:19-EDT
From: David A. Moon <Moon at SCRC-TENEX>
Subject: Non-yucky package names (I think)
To: Scott E. Fahlman <Fahlman at CMU-CS-C>
Cc: Common-Lisp at su-ai
In-reply-to: The message of 31 May 83 03:14-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: Tue, 31 May 1983 03:14 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
New proposal:
Flush the rules for package-name caseification that are found in the
current package chapter. Replace it with the following:
With respect to case, reading, and printing, package names are treated
EXACTLY like symbol names: upcase by default, escape that using / or ||,
observe *PRINT-CASE* on printing, look up using case-sensitive matching.
Note, however, that package names do not become symbols, but are
stashed away in the package object as a string, after case conversion
paralleling that for symbol-names.
So the reader reads a token in just as if it were a symbol. If it hits
a : or #:, it doesn't call INTERN on the token just collected, but
instead calls FIND-PACKAGE. Then it reads the following token, which
had better be a symbol, and interns it.
The various package functions that take package-name strings should
probably take symbol-or-string. If a symbol, you get the
case-conversion for free but create a random symbol in the current
package; if a string, you have to be careful of case.
All the above sounds completely right to me.
So, |fOo:BaR| would be a symbol containing a colon, but |fOo|:|BaR|
is symbol |BaR| in package |fOo|. Notice that I have nothing up my
sleeves and at no time did my hands ever leave the keyboard.
I'm not so sure about allowing vertical bars in package prefixes. It depends
on whether you think of vertical bar as an alternate form of backslash
or as a separate reader-macro whose output is by definition a symbol
(not a token). I could stand this either way, but would slightly prefer
to avoid the complexity of allowing vertical bar in package prefixes.
What we lose is the cute preservation of original case in package names
and the ability to toss around package-name strings without worrying
about case. What we gain is a lot of uniformity: both halves of a
symbol behave the same way.
We could still do case-independent lookup of package names in FIND-PACKAGE
(hence in USE-PACKAGE, export, etc.) and require that no two distinct packages
have names that differ only in case. This would eliminate the need to be careful
about case when typing package names as strings.
∂02-Jun-83 1503 @MIT-MC:Moon@SCRC-TENEX Issue 21: package of #+/#- features
Received: from MIT-MC by SU-AI with TCP/SMTP; 2 Jun 83 15:03:39 PDT
Received: from SCRC-EUPHRATES by SCRC-SPANIEL with CHAOS; Wed 1-Jun-83 23:19:07-EDT
Date: Wednesday, 1 June 1983, 23:14-EDT
From: David A. Moon <Moon at SCRC-TENEX>
Subject: Issue 21: package of #+/#- features
To: Common-lisp at su-ai
I'd like to change my vote from "neutral" to "read features in the same
package as anything else, and put the features associated with the standard
language in the LISP package so they can be typed without prefixes."
In the Maclisp world features are sometimes used to simulate what Common
Lisp does with PROVIDE and REQUIRE. I'm not completely sure, but I believe
that this won't work anymore if feature symbols are subject to packages.
However, I think PROVIDE and REQUIRE are a more reasonable way to do it.
∂02-Jun-83 1506 @MIT-MC:Moon@SCRC-TENEX #+ hair
Received: from MIT-MC by SU-AI with TCP/SMTP; 2 Jun 83 15:05:35 PDT
Received: from SCRC-EUPHRATES by SCRC-SPANIEL with CHAOS; Wed 1-Jun-83 23:49:51-EDT
Date: Wednesday, 1 June 1983, 23:44-EDT
From: David A. Moon <Moon at SCRC-TENEX>
Subject: #+ hair
To: Common-lisp at su-ai
It's been suggested locally that #+ have some escape syntax by which one
could get an arbitrary form evaluated, and read or skip the next form
depending on whether the result was true or false. (The actual suggestion
was that #? do this, but to me it seems clear that this should be a feature
of #+).
One way to do this would be to have any list whose car was not AND, OR, or
NOT just be evaluated. There is an obvious problem with this. If anyone
else has a suggestion I'd like to hear it; perhaps we'll implement it and
if it works out propose it for inclusion in Common Lisp on the second
go-around.
∂02-Jun-83 1522 @MIT-MC:Moon@SCRC-TENEX ~m,n@T in FORMAT
Received: from MIT-MC by SU-AI with TCP/SMTP; 2 Jun 83 15:22:41 PDT
Received: from SCRC-EUPHRATES by SCRC-SPANIEL with CHAOS; Thu 2-Jun-83 01:03:25-EDT
Date: Thursday, 2 June 1983, 00:58-EDT
From: David A. Moon <Moon at SCRC-TENEX>
Subject: ~m,n@T in FORMAT
To: common-lisp at su-ai
The description of this in the Laser manual makes no sense. It says
that ~colrel,colinc@T is equivalent to ~curcol+colrel,colincT where
curcol is the current column. But assuming colrel isn't negative this
never depends on the value of colinc. Instead, I implemented this to
move at least colrel columns to the right, and as many additional columns
(possibly none) as required to get to a multiple of colinc. Is this right?
∂02-Jun-83 1621 EAK@MIT-MC grt optys in data proc
Received: from MIT-MC by SU-AI with TCP/SMTP; 2 Jun 83 16:20:55 PDT
Date: 2 June 1983 19:22 EDT
From: Earl A. Killian <EAK @ MIT-MC>
Subject: grt optys in data proc
To: Guy.Steele @ CMU-CS-A
cc: common-lisp @ SU-AI
In-reply-to: Msg of 2 Jun 1983 0100-EDT () from Guy.Steele at CMU-CS-A
I think that sacrificing horizontal alignment is superior to
losing the datum. Let's just specify that.
∂02-Jun-83 1714 EAK@MIT-MC format force-output
Received: from MIT-MC by SU-AI with TCP/SMTP; 2 Jun 83 17:13:52 PDT
Date: 2 June 1983 20:15 EDT
From: Earl A. Killian <EAK @ MIT-MC>
Subject: format force-output
To: common-lisp @ SU-AI
How about a format command for doing a force-output on the
stream? How about ~!? This would be typicaly be used at the end
of the string, of course.
∂02-Jun-83 1808 FAHLMAN@CMU-CS-C format force-output
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 2 Jun 83 18:08:42 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 2 Jun 83 21:09:17 EDT
Date: Thu, 2 Jun 1983 21:09 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Earl A. Killian <EAK@MIT-MC>
Cc: common-lisp@SU-AI
Subject: format force-output
In-reply-to: Msg of 2 Jun 1983 20:15 EDT from Earl A. Killian <EAK at MIT-MC>
Is there any compelling reason why you can't do the FORMAT, then do a
FORCE-OUTPUT? I hate to further complicate FORMAT for something so
totally random, and I hate to use up a perfectly good character that we
might someday need for aixelsyd mode or something.
-- Scott
∂02-Jun-83 2256 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN The dogma killed ASET
Received: from MIT-MC by SU-AI with TCP/SMTP; 2 Jun 83 22:55:51 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Fri 3-Jun-83 01:58:43-EDT
Date: Friday, 3 June 1983, 01:57-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: The dogma killed ASET
To: Bernard S. Greenberg <BSG%SCRC-TENEX%MIT-MC@SU-DSN>
Cc: common-lisp@su-ai
In-reply-to: The message of 2 Jun 83 16:35-EDT from Bernard S. Greenberg <BSG%SCRC-TENEX at MIT-MC>
Date: Thursday, 2 June 1983, 16:35-EDT
From: Bernard S. Greenberg <BSG%SCRC-TENEX@MIT-MC>
While writing some common lisp code today, I was reminded that ASET
was removed because "You should be using SETF". Unfortunately,
what I wanted to do was (apply #'aset value array list-of-subscripts),
a very reasonable thing in a recursive array-processing program,
and I find there is no way to do this in Common Lisp. Opinions?
The following works and is in our implementation now. It isn't as complicated
as it looks at first, since almost all of it is error-checking. I admit that
it's rather a kludge, and maybe we should say that knowledge of APPLY has to
be built into SETF (actually into GET-SETF-METHOD). But one way or the other
it seems eminently reasonable for
(SETF (APPLY #'AREF ARRAY SUBSCRIPTS) VALUE)
to be defined to work.
Opinions?
Code:
;Pretend the last argument is only a single argument, get the setf method
;for that form, then stick APPLY back in. Since this doesn't understand
;the code it is generating in any deep way, it can be fooled into generating
;wrong code when it should have generated an error at macroexpansion time
;saying that it doesn't understand what it's doing.
(DEFINE-SETF-METHOD APPLY (FUNCTION &REST ARGS)
(IF (AND (LISTP FUNCTION)
(= (LIST-LENGTH FUNCTION) 2)
(MEMBER (FIRST FUNCTION) '(QUOTE FUNCTION))
(SYMBOLP (SECOND FUNCTION)))
(SETQ FUNCTION (SECOND FUNCTION))
(FERROR "~S is not a constant function; APPLY of it is~@
not understood as a generalized variable" FUNCTION))
(MULTIPLE-VALUE-BIND (VARS VALS STORE-VARS STORE-FORM ACCESS-FORM)
(GET-SETF-METHOD-MULTIPLE-VALUE (CONS FUNCTION ARGS))
(LET ((LIST-VAR (LOOP FOR VAR IN VARS AND VAL IN VALS
WHEN (EQ VAL (CAR (LAST ARGS))) RETURN VAR)))
(OR (AND LIST-VAR
(EQ (CAR (LAST ACCESS-FORM)) LIST-VAR)
(EQ (CAR (LAST STORE-FORM)) LIST-VAR))
(FERROR "APPLY of ~S not understood as a generalized variable" FUNCTION))
(VALUES VARS VALS STORE-VARS
`(APPLY #',(FIRST STORE-FORM) . ,(REST STORE-FORM))
`(APPLY #',(FIRST ACCESS-FORM) . ,(REST ACCESS-FORM))))))
∂02-Jun-83 2318 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN typep of array
Received: from MIT-MC by SU-AI with TCP/SMTP; 2 Jun 83 23:14:45 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Fri 3-Jun-83 02:14:16-EDT
Date: Friday, 3 June 1983, 02:13-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: typep of array
To: Steele%CMU-CS-C@SU-DSN
Cc: Common-Lisp@SU-AI
The line that is commented out in the enclosed code fragment seems like
a good example of a deficiency in the Common Lisp type system. There is
no way in a single typecase to make this discrimination, i.e. to have
a clause that handles all arrays whose elements are guaranteed to be
integers. One has to have a typecase clause for plain array, inside
of which are conditions using array-element-type and subtypep, which
is ugly.
(defun write-binary-object (object type binary-output-stream)
(typecase object
...
; ((array integer) (write-binary-object-packed-array object binary-output-stream))
(array (write-binary-object-array object binary-output-stream))
...))
∂02-Jun-83 2327 FAHLMAN@CMU-CS-C Another ballot
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 2 Jun 83 23:27:02 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 3 Jun 83 02:27:07 EDT
Date: Fri, 3 Jun 1983 02:27 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: common-lisp@su-ai
Subject: Another ballot
Ballot A:
This is a follow-up to the Memorial Day ballot, raising some issues that
came up since the earlier ballot went out. Please respond by Saturday
evening. (My apologies to those of you who don't work on weekends, if
any such exist. You've still got all day Friday.) With some luck and a
lot of hard work, we may be able to wrap this whole process up by early
next week, and get an final manual out (minus proofreading and some work
on the index).
There are still some unresolved issues relating to the file-name stuff,
so there may be a supplementary ballot making some proposals in that
area.
---------------------------------------------------------------------------
A1. Proposed that we add BSG's PARSE-INTEGER function in place of the
defunct PARSE-NUMBER.
[I am mildly in favor. It is easy to implement, and useful in writing
user interfaces.]
---------------------------------------------------------------------------
A2. Propose that PROCLAIM, the replacement for top-level DECLARE, will
evaluate its arguments as a normal function. Note that PROCLAIM must be
wrapped in an implicit (EVAL-WHEN (COMPILE LOAD EVAL)...) in order to
work, so whatever the args are, they must be evaluable at compile time.
[Several people, most notably Moon, proposed this in their response to
the earlier ballot. One advantage is that you can now easily include
constants declared earlier in the file in the body of a proclamation.
The disadvantages are that you have to quote each proclamation in the
usual case, and that it's a little harder to convert old DECLARE forms.
I'm in favor or the proposal.]
---------------------------------------------------------------------------
A3. Indicate which of the following you could live with, and which you
prefer:
a. The old scheme in which package names retain their case, but are
matched in a case-insensitive way. We would have to outlaw :, \, |,
other readmacro characters, and whitespace in package names.
b. My proposal to treat the package name part of a qualified symbol
EXACTLY like the symbol part, except that no symbol is created. This
would allow things like |fOo|:|BaR|. It has the disadvantage that |
can no longer be a macro returning a symbol but must be treated as a
sort of escape character. This complicates the reader. It also means
that when the package name is entered as a string, you have to be
careful of case.
c. A proposal by Moon to allow slashes (and therefore any character) in
package names, but not vertical bars. Also to do symbol-like case
conversion on package names (so that they can be read with a subset of
the symbol-reading machinery) but case-insensitive lookup, so that users
don't have to worry about case when typing in package names as strings.
This would mean that two distinct packages could not have names that
differ only in case. The effect is just like (a) above, except that you
can get the weird characters in using the \ convention.
[ I could live with any of these and have in fact oscillated between B
and C. Right now I favor B. As KMP points out, people find it totally
intuitive, and it's not THAT much extra work for the implementor.]
---------------------------------------------------------------------------
A4. Moon has pointed out that VECTOR-PUSH and VECTOR-PUSH-EXTEND take
their arguments in an order that is inconsistent with PUSH. Propose to
fix this.
[In favor, of course.]
---------------------------------------------------------------------------
A5. Add KMP's (NTH-VALUE n form) for picking up one value from a form
that returns multiple values.
[I am mildly opposed to this. As Moon points out, this would have to be
0-based and would be non-intuitive for that reason. In addition, it is
rare to want some single value other than the first.]
---------------------------------------------------------------------------
A6. Propose to add GSB's proposal for a set of primitives to create
named structures. (This was in recent mail -- I don;t want to repeat
the whole thing here.)
[I oppose this. A nearly portable DEFSTRUCT package can be created now that
contains implementation-dependent forms in about three places. That
doesn't seem like a sufficient maintenance headache to justify adding a
whole new level of user-visible standardized machinery.]
---------------------------------------------------------------------------
A7. EAK has asked that we vote on this: Propose to eliminate SET and
FSET from Common Lisp in favor of (SETF (SYMBOL-VALUE ...) ...) and
(SETF (SYMBOL-FUNCTION ...) ...).
[I strongly oppose this. I just don't want to type that much stuff in
order to get this job done.]
---------------------------------------------------------------------------
A8. EAK has also asked that we vote on this: Propose that in Common Lisp
it is an error to do (apply '(lambda ...) ...).
[I am not sure of all the implications of this. My inclination is to
leave this the way it is right now.]
---------------------------------------------------------------------------
A9. Propose that we reinstate VREF. This is a fairly useless synonym
for AREF with one index, but people keep expecting to find it there,
even some who have not been through all the oscillation on this.
[Mildly in favor.]
---------------------------------------------------------------------------
A10. Add an optional integer seed to MAKE-RANDOM-STATE. A given seed in
a given implementation always creates a random state object that
generates the same sequence of "random" numbers, but different seeds
create random states that are <mumble, handwave> unrelated. As it now
stands, the only way to create distinct but repeatable random states is
to start from copies of the same state and run RANDOM for (very) different
numbers of cycles.
[I am in favor, unless there are implementation problems of which I am
unaware.]
---------------------------------------------------------------------------
A11. Propose that we adopt the APPLYHOOK feture, as specified by Moon.
[I am in favor of this. It makes possible more refined forms of
single-stepping, at the cost of some minor extra hassle for the
implementor. (Our lexical EVAL does not actually do a real APPLY, but
could arrange to if *APPLYHOOK* were non-null.) ]
Rationale:
When stepping through an interpreted program, it is desirable to be able
to pause before each evaluation, to pause after each evaluation so that
the value can be examined or changed. These operations can be done with
the evalhook feature. It is also desirable to pause before invoking
a function (whether a user function or a system function), so that the
values of the arguments may be examined or modified. This requires the
applyhook feature, or else requires duplicating an unnecessarily large
part of the EVAL function.
The applyhook feature catches only APPLY operations done by EVAL. It
does not catch APPLY done in other parts of the interpreter (i.e. by
special forms: CATCH-ALL and UNWIND-ALL are the only ones in Table 5-1
that would do an APPLY), nor does it catch APPLY or FUNCALL operations
done by functions (MAPCAR for instance). Stepping through APPLY
operations done by a function such as MAPCAR are best done by
intercepting the call to MAPCAR, using the apply hook, and substituting
a different first argument.
Note:
The writeups for APPLYHOOK and *APPLYHOOK* should be largely copied
from the writeups for EVALHOOK and *EVALHOOK*. I have not made any
attempt to do this, but have just indicated the differences.
New variable *APPLYHOOK*: (analogous to *EVALHOOK*)
When non-NIL, EVAL behaves in a special way. Whenever it is about to
apply a function to the values of the function's arguments, which have
already been evaluated, instead it calls the value of *APPLYHOOK* with
two arguments: the function and its list of arguments. Whatever values
the hook function returns are taken as the results.
The list of arguments is just like an &rest argument in its volatility.
If the hook function just calls APPLY on its first two arguments, EVAL
would behave in its normal way except a little slower. (Of course the
preceding sentence isn't true in a lexical interpreter, where the
internal environment-taking APPLY isn't accessible to the user except
through the APPLYHOOK function, below.)
The apply hook function gets additional "env" arguments just like the
eval hook function.
EVAL binds both *EVALHOOK* and *APPLYHOOK* to NIL around calls to either of them.
EVALHOOK takes an extra argument:
*APPLYHOOK* is bound to the third argument (before the "&rest env"), a function
or NIL.
New function APPLYHOOK: (analogous to EVALHOOK)
The arguments are function, arglist, evalhook, applyhook (&rest env).
This function is completely analogous to EVALHOOK and is to be called by
*APPLYHOOK* functions in the same way that EVALHOOK is to be called by
*EVALHOOK* functions, to "jump back into the interpreter".
Macros and special forms:
*APPLYHOOK* does not affect the invocation of a macro expansion function.
*APPLYHOOK* has no effect on the evaluation of special forms.
---------------------------------------------------------------------------
A12. Add a simple form of destructuring LET macro. DLET would allow
arbitrary list or tree structures in place of the LET variables. The
leaves would be symbols, the variables to bind. The LET values would be
picked apart according to these patterns and the pieces assigned to the
variables.
[ I propose this with some trepidation. I am in favor of destructuring
if it goes just this far, but every time we've brought this up someone
pops up with a proposal to destructure vectors, arrays, structures,
character objects, bignums, and the family cat, and to let destructuring
creep into all parts of the language. Can we vote on the proposal above
and let people who want more complex destructuring do it as a
non-standard extension or wait till the seond edition? ]
---------------------------------------------------------------------------
A13. A modification to INTERN and FIND-SYMBOL, suggested by Moon:
Both of these functions return two values. The first is the symbol that
was found or created. (FIND-SYMBOL does not create a new symbol, but
returns NIL for the first value if no existing symbol was found.) The
second argument is NIL if no existing symbol was found and takes on one
of three values if a symbol was found:
:INTERNAL
:EXTERNAL
:INHERITED (implies internal).
We can now flush FIND-EXTERNAL-SYMBOL. If you want this, call
FIND-SYMBOL and see if the second value is :EXTERNAL.
[I am in favor of this.]
---------------------------------------------------------------------------
A14: Proposed by KMP that we rename MULTIPLE-VALUE to MULTIPLE-VALUE-SETQ.
[ Yes!!! Long overdue. We don't want users to favor this over
MULTIPLE-VALUE-BIND just because the name seems to imply that this is
the canonical MV function. ]
---------------------------------------------------------------------------
A15: Steele propose the following:
There has been a lot of flak about the decision that every
implementation must support arrays of rank up to 63. There are similar
problems with numbers of arguments, and Moon has raised an objection
concerning the equating of valid array dimensions with fixnums.
I propose that we recant a bit, and set no hard limits, but realize that
programs may not be portable by reason of pushing on those limits. So
that programs may probe the environment, introduce these constants:
ARRAY-RANK-LIMIT As before, the implementation only supports arrays
of rank less than this constant.
ARRAY-DIMENSION-LIMIT Limit on each array dimension.
ARRAY-TOTAL-SIZE-LIMIT Limit on total size of an array.
CALL-ARGUMENTS-LIMIT Limit on number of arguments in a function call.
CALL-VALUES-LIMIT Limit on number of multiple values a call can
return.
We may think of other implementation parameters to make available as
well. The intent is that no hard limit is set, but that each
implementation should make these numbers as large as practicable.
[ I'm in favor. ]
---------------------------------------------------------------------------
A16. Guy proposes that we get rid of MACRO, which is a trap for
unsuspecting users who ought to be enjoying the benfits of DEFMACRO.
We need something for DEFMACRO to expand into. Guy proposes a function
named SET-MACRO that takes two evaluated arguments: the symbol that is
to be defined as a macro and the expansion function. So if we want to
define a macro named FOO and its expansion function is
(LAMBDA (CALLFORM) ...), we (or rather defmacro) would use
(SET-MACRO 'FOO #'(lambda (callform) ...))
In effect, SET-MACRO does whatr one might express as
(SETF (SYMBOL-FUNCTION 'FOO)
(make-a-macro-object #'(LAMBDA (CALLFORM) ...)))
except that SET-MACRO hides the existence of this odd macro-object
(if indeed that is the way it is implemented internally).
[ I'm in favor. ]
---------------------------------------------------------------------------
A17. Per EAK's suggestion, require (integerp 4/2) to be true and also
require (integerp (complex 4 0)) to be true. That is, rationals always
reduce to canonical form, and so do Gaussian rationals. More specifically,
any attempt to create a rational whose value is integral will in fact
result in an integer; and any attempt to create a complex number whose
real part is rational and whose imaginary part is the integer zero will
result in a rational, namely the real part. If either part of a complex
number is floating-point then the complex number must remain complex.
Thus all Gaussian rationals have a unique canonical representation,
while (totally or partially) floating-point numbers maintain their
data type more distinctly (which is important for numerical reasons:
in IEEE arithmetic it is very important to distinguish 1.0, 1.0+0.0i,
and 1.0-0.0i !).
[ Guy supports this. I'm indifferent. ]
∂03-Jun-83 0649 @MIT-MC:BSG%SCRC-TENEX%MIT-MC@SU-DSN Another ballot
Received: from MIT-MC by SU-AI with TCP/SMTP; 3 Jun 83 06:49:18 PDT
Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Fri 3-Jun-83 09:45:34-EDT
Date: Friday, 3 June 1983, 09:44-EDT
From: Bernard S. Greenberg <BSG%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Another ballot
To: Fahlman%CMU-CS-C@SU-DSN, common-lisp@su-ai
In-reply-to: The message of 3 Jun 83 02:27-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: Fri, 3 Jun 1983 02:27 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
A1. Proposed that we add BSG's PARSE-INTEGER function in place of the
defunct PARSE-NUMBER.
Yes. I'd like to modify the spec to say that it does not parse a Common
Lisp <integer>, but a sequence of digits to produce a Common Lisp <integer>.
The person writing the calling program and its documentation choose the
input base, not the user.
A2. Propose that PROCLAIM, the replacement for top-level DECLARE, will
evaluate its arguments as a normal function. Note that PROCLAIM must be
wrapped in an implicit (EVAL-WHEN (COMPILE LOAD EVAL)...) in order to
work, so whatever the args are, they must be evaluable at compile time.
Yes.
A3. Indicate which of the following you could live with, and which you
prefer:
b. or c.
A4. Moon has pointed out that VECTOR-PUSH and VECTOR-PUSH-EXTEND take
their arguments in an order that is inconsistent with PUSH. Propose to
fix this.
Yes. What ever happened to my observation about SUBSTITUTE-IF's argument
order inconsistency?
A5. Add KMP's (NTH-VALUE n form) for picking up one value from a form
that returns multiple values.
In favor.
[I am mildly opposed to this. As Moon points out, this would have to be
0-based and would be non-intuitive for that reason.
Would 1-based be MORE intuitive if you know Common Lisp?
In addition, it is
rare to want some single value other than the first.]
I disagree with this. This is precisely for that case where you do, and
there is really no other way to handle it.
---------------------------------------------------------------------------
A6. Propose to add GSB's proposal for a set of primitives to create
named structures. (This was in recent mail -- I don;t want to repeat
the whole thing here.)
Mildly opposed.
A7. EAK has asked that we vote on this: Propose to eliminate SET and
FSET from Common Lisp in favor of (SETF (SYMBOL-VALUE ...) ...) and
(SETF (SYMBOL-FUNCTION ...) ...).
Can't say. I'm not wise enough to make a tradeoff between consistency and
convenience on a case-by-case basis. I am reminded of the guy in "Life of
Brian" who says, "*I'M* not different!": the consistent primitive-less
setters are certainly consistent with each other, and with the rest they
are inconsistent. If we really believe that SET and FSET are must-have's,
I would wish the restoration of PUTPROP on identical grounds.
A8. EAK has also asked that we vote on this: Propose that in Common Lisp
it is an error to do (apply '(lambda ...) ...).
Not sure.
A9. Propose that we reinstate VREF. This is a fairly useless synonym
for AREF with one index, but people keep expecting to find it there,
even some who have not been through all the oscillation on this.
Opposed.
A10. Add an optional integer seed to MAKE-RANDOM-STATE. A given seed in
a given implementation always creates a random state object that
generates the same sequence of "random" numbers, but different seeds
create random states that are <mumble, handwave> unrelated. As it now
stands, the only way to create distinct but repeatable random states is
to start from copies of the same state and run RANDOM for (very) different
numbers of cycles.
In favor.
A11. Propose that we adopt the APPLYHOOK feture, as specified by Moon.
In favor.
A12. Add a simple form of destructuring LET macro. DLET would allow
arbitrary list or tree structures in place of the LET variables. The
leaves would be symbols, the variables to bind. The LET values would be
picked apart according to these patterns and the pieces assigned to the
variables.
I propose we hold off until we understand what we intend to do with
destructuring, or make such a thing as proposed a yellow-pages extension.
A13. A modification to INTERN and FIND-SYMBOL, suggested by Moon:
Both of these functions return two values. The first is the symbol that
was found or created. (FIND-SYMBOL does not create a new symbol, but
returns NIL for the first value if no existing symbol was found.) The
second argument is NIL if no existing symbol was found and takes on one
of three values if a symbol was found:
:INTERNAL
:EXTERNAL
:INHERITED (implies internal).
We can now flush FIND-EXTERNAL-SYMBOL. If you want this, call
FIND-SYMBOL and see if the second value is :EXTERNAL.
In favor.
A14: Proposed by KMP that we rename MULTIPLE-VALUE to MULTIPLE-VALUE-SETQ.
Indeed!
A15: Steele propose the following:
There has been a lot of flak about the decision that every
implementation must support arrays of rank up to 63. There are similar
problems with numbers of arguments, and Moon has raised an objection
concerning the equating of valid array dimensions with fixnums.
I propose that we recant a bit, and set no hard limits, but realize that
programs may not be portable by reason of pushing on those limits. So
that programs may probe the environment, introduce these constants:
This, to me, is not as transparently clear as it may seem. It is very hard
to parameterize your program for variable limits on array rank. This is
not the same as "maximum array size" or "maximum string size", against
whose effects you can easily parameterize your program. While I am in favor
of the new variables, which say what the implementation's limits are, I
think that it is strongly in the interests of portability to impose SOME
lower limit on maximum array rank, even if it is 3 or 4 or 10.
A16. Guy proposes that we get rid of MACRO, which is a trap for
unsuspecting users who ought to be enjoying the benfits of DEFMACRO.
We need something for DEFMACRO to expand into. Guy proposes a function
named SET-MACRO that takes two evaluated arguments: the symbol that is
to be defined as a macro and the expansion function. So if we want to
define a macro named FOO and its expansion function is
(LAMBDA (CALLFORM) ...), we (or rather defmacro) would use
(SET-MACRO 'FOO #'(lambda (callform) ...))
In effect, SET-MACRO does whatr one might express as
(SETF (SYMBOL-FUNCTION 'FOO)
(make-a-macro-object #'(LAMBDA (CALLFORM) ...)))
except that SET-MACRO hides the existence of this odd macro-object
(if indeed that is the way it is implemented internally).
In favor.
A17. Per EAK's suggestion, require (integerp 4/2) to be true and also
require (integerp (complex 4 0)) to be true. That is, rationals always
reduce to canonical form, and so do Gaussian rationals.
Strongly in favor.
∂03-Jun-83 0835 GINDER@CMU-CS-C Re: Another ballot
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 3 Jun 83 08:35:07 PDT
Received: ID <GINDER@CMU-CS-C>; 3 Jun 83 11:35:02 EDT
Date: 3 Jun 83 11:35:02 EDT
From: Ginder@CMU-CS-C
Subject: Re: Another ballot
To: Fahlman@CMU-CS-C
cc: common-lisp@SU-AI
In-Reply-To: Your message of 3 Jun 83 02:41:25 EDT
a1. don't care
a2. OK
a3. C, but could live with B grumblingly
a4. yes
a5. no
a6. no
a7. no
a8. no
a9. yes
a10. yes
a11. yes
a12. weak no (could live with yes, again grumblingly)
a13. yes
a14. yes
a15. yes
a16. yes
a17. yes
--Joe
-------
∂03-Jun-83 0838 @MIT-MC:DLW%SCRC-TENEX%MIT-MC@SU-DSN Another ballot
Received: from MIT-MC by SU-AI with TCP/SMTP; 3 Jun 83 08:38:27 PDT
Received: from SCRC-BORZOI by SCRC-TENEX with CHAOS; Fri 3-Jun-83 11:38:02-EDT
Date: Friday, 3 June 1983, 11:37-EDT
From: Daniel L. Weinreb <DLW%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Another ballot
To: Fahlman%CMU-CS-C@SU-DSN, common-lisp@su-ai
In-reply-to: The message of 3 Jun 83 02:27-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
A1: Yes.
A2: Yes.
A3: B and C are both OK; no real preference.
A4: Yes.
A5: Yes. It's not rare to want some single value other than the first.
I see nothing non-intuitive about having it be 0-based; everything is
0-based.
A6: (No opinion, I haven't been following this issue.)
A7: No. I realize it's a highly arbitrary tradeoff.
A8:
A9: No. This is completely redundant; there's no need for it.
A10: Yes.
A11: Yes.
A12: I am basically in favor of this. I am especially in favor of this
if we allow list-oriented destructuring in DEFMACRO patterns (which I
think we ought to) so that there's only one kind of destructuring
floating around. The other kind of destructuring is a neato thing but
I'd rather leave it in the yellow pages for now. You should figure out
whether DLET has parallel syntax to LET, and therefore lets you bind
several variables, or whether it's like our DESTRUCTURING-BIND, which
only takes one variable and one destructuring pattern. I'd prefer the
latter, but then the name DLET would suggest the wrong kind of syntax.
(Also, if we keep the name DLET and make the syntax like LET then symmetry
demands a DLET*, which I don't think is something we really need.) So I'd
rather use the latter syntax (one variable), and change the name. I realize
DESTRUCTURING-BIND isn't very good. In fact, the use of the word "structure"
in this context isn't very consistent with the usual CL meaning of "structure",
anyway.
A13: Yes.
A14: Yes.
A15: I quite clearly remember the discussion in which this change was
made. The point was, and still is, that if there is no minimum that
every implementation must support, then no program that uses 2-D arrays
is guarateed to be portable. I think this is a strong and obvious
argument. What was all the flak about: was 63 too big? Steele just
made up that number randomly and we all agreed. It's OK with me if we
change it to 7 or even to 3, but let's keep some minimum.
In fact, by the same reasoning, there ought to be a minimum on the
values of call-arguments-limit and call-values-limit, for the same
reason!
Having the variables is probably a good idea anyway.
A16: Yes.
A17: Yes, definitely.
∂03-Jun-83 0907 @MIT-ML:DLW%SCRC-TENEX%MIT-ML@SU-DSN Another ballot
Received: from MIT-ML by SU-AI with TCP/SMTP; 3 Jun 83 09:06:04 PDT
Received: from SCRC-BORZOI by SCRC-TENEX with CHAOS; Fri 3-Jun-83 12:03:58-EDT
Date: Friday, 3 June 1983, 12:03-EDT
From: Daniel L. Weinreb <DLW%SCRC-TENEX%MIT-ML@SU-DSN>
Subject: Another ballot
To: Fahlman%CMU-CS-C@SU-DSN, common-lisp@su-ai
In-reply-to: The message of 3 Jun 83 02:27-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Sorry, I never got back to A8. I'm sure I don't understand the
implications of all of this myself, either. However, on page 42
it says quite explicitly that a lambda expression is not a form
and cannot be meaningfully evaluated. So you cannot turn
(apply '(lambda ...) ...) into (apply (lambda ...) ...)
and expect it to work. Perhaps the suggestion is that you
have to turn it into (apply #'(lambda ...) ...)? Presumably
the restriction would also apply to funcall, mapcar, and anything
else that accepts a "function" as an argument?
If you read section 2.13 (p 23), it doesn't even say that "lexical
closures" are functions, even though the description of function (p 62)
talks about returning lexical closures. In fact, Chapter 2 doesn't say
much about lexical closures at all; it's not clear how they fit into the
type system. 2.13 also says that lambda expressions are functions; A8
would change this as well.
My gut feeling at this point is to say No to A8, continue to allow
lambda-expressions to act as functions, but clear up the role of
functions in the language by making 2.13 more correct and having the
definitions of apply and funcall refer to 2.13. I think this is partly
that I'm being conservative, and hoping the ease the conversion task
ahead, but also that the implications just aren't clear enough.
∂03-Jun-83 0918 @MIT-MC:DLW%SCRC-TENEX%MIT-MC@SU-DSN The dogma killed ASET
Received: from MIT-MC by SU-AI with TCP/SMTP; 3 Jun 83 09:13:07 PDT
Received: from SCRC-BORZOI by SCRC-TENEX with CHAOS; Fri 3-Jun-83 11:45:48-EDT
Date: Friday, 3 June 1983, 11:44-EDT
From: Daniel L. Weinreb <DLW%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: The dogma killed ASET
To: Moon%SCRC-TENEX%MIT-MC@SU-DSN
Cc: common-lisp@su-ai
In-reply-to: The message of 3 Jun 83 01:57-EDT from David A. Moon <Moon%SCRC-TENEX%MIT-MC at SU-DSN>
One thing's for sure: this is a nifty demo of the power of the new
5-values SETF scheme. My taste-buds are oscillating between calling
this a kludge and calling it elegant; when two things can be put
together in an unexpected way to produce a result that's unexpected but
useful, it can be hard to say whether that constitutes a demonstration
of inherent elegance or a programming trick. Certainly I don't think
that there's anything better for (setf (apply #'aref ...) ...) to expand
into. If nobody comes up with any real problem with this, I'd say it
constitutes a solution to the problem. It's probably worth documenting
explicitly somewhere since a lot of people would never guess that this
might work.
∂03-Jun-83 0925 @MIT-MC:Cassels%SCRC-TENEX%MIT-MC@SU-DSN [Moon at SCRC-TENEX: short-float-negative-epsilon]
Received: from MIT-MC by SU-AI with TCP/SMTP; 3 Jun 83 09:24:51 PDT
Received: from SCRC-CONNECTICUT by SCRC-TENEX with CHAOS; Fri 3-Jun-83 12:24:18-EDT
Date: Friday, 3 June 1983, 12:23-EDT
From: Robert A. Cassels <Cassels%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: [Moon at SCRC-TENEX: short-float-negative-epsilon]
To: Common-Lisp@su-ai
Return-path: <Moon@SCRC-TENEX>
Received: from SCRC-BULLDOG by SCRC-TENEX with CHAOS; Wed 30-Mar-83 17:22:23-EST
Date: Wednesday, 30 March 1983, 17:20-EST
From: David A. Moon <Moon@SCRC-TENEX>
Subject: short-float-negative-epsilon
To: Guy.Steele@CMU-CS-A
Cc: common-lisp%su-ai@su-score, Cassels@SCRC-TENEX
Am I correct in guessing that the arguments to - in the Lisp-code definition
of short-float-negative-epsilon in the Laser edition are backwards? The
code as it stands is clearly bogus. If the arguments to - are backwards,
then negative-epsilon would be the smallest positive number that you
can subtract from 1.0 and get a different answer than 1.0.
------
This hasn't been fixed in the latest version of the manual we have.
∂03-Jun-83 1009 eak@s1-c 2nd ballot
Received: from S1-C by SU-AI with TCP/SMTP; 3 Jun 83 10:08:49 PDT
Date: 3 Jun 1983 10:05:48-PDT
From: eak at s1-c
To: Common-Lisp@sail
Subject: 2nd ballot
A1. Yes
A2. Yes
A3. c or b
A4. Yes
A5. Yes
A6. wait
A7. Yes
A8 [Lists with car eq lambda are functions]. Yes, there is no point in forcing
an implementation to do this as it is unnecessary in writing portable
Common Lisp programs. I'm not even sure that these are of any use at all;
no one defended lists as functions when their removal was suggested in the
mailing list months ago, which is why I asked for it to be on the ballot.
A9. No
A10 [Add optional integer argument to MAKE-RANDOM-STATE]. No. The statement
in the ballot is incorrect -- according to the laser edition,
(MAKE-RANDOM-STATE T) gets you a new state object "that has been `randomly'
initialized by some means (such as by a time-of-day clock)."
A11. Yes
A12. No opinion.
A13. Yes
A14. Yes
A15. I agree with BSG.
A16. Wouldn't it be better to rename MACRO-P to MACRO-FUNCTION and then
(MACRO-FUNCTION <symbol>) would get you the function, and
(SETF (MACRO-FUNCTION <symbol>) #'(LAMBDA ...)) would set it?
However, I seem to remember that Moon had objections to having
MACRO-P return a function; was that resolved before the laser
edition went out, or is the laser edition out-of-date on this?
A17. Yes
∂03-Jun-83 1014 eak@s1-c compiled-function
Received: from S1-C by SU-AI with TCP/SMTP; 3 Jun 83 10:14:24 PDT
Date: 3 Jun 1983 10:12:51-PDT
From: eak at s1-c
To: Common-Lisp@sail
Subject: compiled-function
It is not at all clear to me what this type really is, or what its corresponding
predicate does. Does a closure where the code is compiled qualify, or is it
just a pointer to compiled code? If it is the latter, it may not even be an
applicable object in S1 lisp, if I understand S1 lisp properly, because
functions are always closures. That makes the word "function" misleading
in its name. Anyway, clarification on this is needed.
Also, as DLW points out, there the result of the function special form is
not documented to be a function in the laser edition. This is presumably
an oversight, but it raises the question, do we need a closure type and
a closurep predicate?
∂03-Jun-83 1049 @MIT-MC:BSG%SCRC-TENEX%MIT-MC@SU-DSN Another ballot
Received: from MIT-MC by SU-AI with TCP/SMTP; 3 Jun 83 10:48:52 PDT
Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Fri 3-Jun-83 13:46:14-EDT
Date: Friday, 3 June 1983, 13:45-EDT
From: Bernard S. Greenberg <BSG%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Another ballot
To: Fahlman%CMU-CS-C@SU-DSN, common-lisp@su-ai
In-reply-to: The message of 3 Jun 83 02:27-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: Fri, 3 Jun 1983 02:27 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
A8. EAK has also asked that we vote on this: Propose that in Common Lisp
it is an error to do (apply '(lambda ...) ...).
What are we talking about anyway here, '(lambda ) vs. #'(lambda ), or funcall/apply'ing
internal lambda expressions, or apply as opposed to funcall of internal lambdas?
I don't remember EAK's original remark.
∂03-Jun-83 1126 RPG
A1. Ok.
A2. Ok.
A3. Ok for B & C. B is better than C.
A4. Ok
A5. No need for this.
A6. No.
A7. No, though it may be `more elegant' in some ways.
A8. No. But I would try to discourage such forms.
A9. Yes. S-1 Lisp uses simple vectors, and I find it refreshing to be able to
understand vector code at a glance, and I don't like writing unnecessary
macros all the time.
A10. Who the hell cares???
A11. Ok. Let Moon write the interpreterm though.
A12. Put this in the yellow pages as a macro package. I won't object to it in
the white pages, though.
A13. Ok.
A14. Overdue? I thought this was the original name that was proposed. In fact,
I proposed it and someone wanted it changed. I generally favor my own
proposals.
A15. Ok. I cannot parse `the equating of valid array dimensions with fixnums.'
Does this mean he wants them to be complex numbers? Reals? Transcendentals?
I though Moon was the one who said that it's about time people stopped
designing languages based on implementability? I guess that's only
true for features his machine can implement well. I want FFT in CL!!!
All the matrix operations too!
A16. Ok.
A17. Ok.
Scott. I'm sorry for being so sarcastic, but every now and then I get the
urge to rename this Lisp Moon-lisp or Symbolics-Lisp. I suppose, though,
that it is in Symbolics's best interest to make CL just complex enough
that a 3600 can run it and no lesser machine can. If they can also flush
stock hardware in the bargain, so much the better. My fantasy is to make
it just complex enough to rule out anything less than an S-1. Then we
could start over, and use good taste *and* a modest appetite.
-rpg-
∂03-Jun-83 1153 ALAN@MIT-MC Another ballot
Received: from MIT-MC by SU-AI with TCP/SMTP; 3 Jun 83 11:53:01 PDT
Date: 3 June 1983 14:53 EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: Another ballot
To: Fahlman @ CMU-CS-C
cc: common-lisp @ SU-AI
1. Yes.
2. Yes.
3. C
4. Yes.
5. Yes. It should be zero-based as Moon points out.
6. As the implementor of defstruct, let me point out that it makes no
difference which way this vote goes. Even if you don't write these
functions into the Common Lisp spec, I am likely to write a portable
defstruct that requires you to have them anyway.
7. Flush FSET, but keep SET. I type "(SET + ...)" to the read-eval-print
loop all the time. FSET I never use, it has a poor name, and it
isn't even a traditional function.
8. Abstain.
9. Don't care.
10. Yes.
11. Yes.
12. Yes.
13. Yes.
14. Yes.
15. I would suggest 5 as the largest array rank required to be supported.
16. Abstain.
17. Yes. I suggested this last December along with some other suggestions
about Gaussian rationals. (I suggested that the functins GCD,
NUMERATOR, and DENOMINATOR have their domains appropriately inlarged,
for example.) Does this indicate that my other suggestions were lost
or forgotten?
∂03-Jun-83 1223 BENSON@SPA-NIMBUS Function names and function objects
Received: from SU-DSN by SU-AI with PUP; 03-Jun-83 12:23 PDT
Received: From MIT-XX by SU-DSN.ARPA; Fri Jun 3 12:24:36 1983
Date: Friday, 3 June 1983, 12:22-PDT
From: BENSON at SPA-Nimbus
Subject: Function names and function objects
To: Common-Lisp at Sail
I had a feeling this would finally come up when we had to vote on it.
Apparently several people missed my message on this subject about a
month ago. I will resend it for the benefit of those people. Let me
also restate some important points:
Function names (lambda expressions and symbols) are not the same as
function objects (lexical closures and compiled code objects). The
special forms FUNCTION and QUOTE are only related by historical
confusion. Function evaluation (the process which produces a function
object from a function name) is entirely unrelated to function
application. If the semantics of a function object depend on the
environment in which a name is evaluated to produce it, the function
name and the function object cannot be the same. It was an
implementation convenience in dynamically-scoped Lisps, where the
semantics of the function object depended only on the environment at
function application time, to make function names and function objects
the same. In a lexically-scoped Lisp, a single function name may be
evaluated in different places or at different times to produce different
function objects.
This means that symbols as well as lambda expressions would be
disallowed as function objects. It may be a bitter pill to swallow, but
it would be extremely unfortunate if this confusion were to be continued
in Common Lisp. If it is too hard to convert programs immediately,
perhaps we can have a "phase-out" period, where symbols applied as
functions will be evaluated via SYMBOL-FUNCTION, and lambda expressions
when applied will be closed in the null lexical environment (certainly
NOT in the enviroment of the call!). Implementations would warn that
this usage is archaic, and at some agreed-upon time in the future the
warning would change into an error.
This is not simply a matter of being dogmatic. We would laugh at the
suggestion that taking the CDR of a symbol, if it happened to be a
special variable bound to a list, would return the CDR of the list it
was bound to. Yet this is exactly analogous to using the dynamic
function value of a symbol if it happens to get applied. We should not
confuse function evaluation with function application just because they
most commonly happen at about the same time in ordinary function calls.
-- Eric
∂03-Jun-83 1238 BENSON@SPA-NIMBUS Earlier message on function objects
Received: from SU-DSN by SU-AI with PUP; 03-Jun-83 12:38 PDT
Received: From MIT-XX by SU-DSN.ARPA; Fri Jun 3 12:39:32 1983
Date: Friday, 3 June 1983, 12:38-PDT
From: BENSON at SPA-Nimbus
Subject: Earlier message on function objects
To: Common-Lisp at Sail
Here is the message I sent about a month ago. The last paragraphs
suggests some system-building tools. Purists may object to these as
violating referential transparency. They are not essential for most
users, but every system will need something like them, so they might as
well be portable.
--------------------
-*-Mode:Text-*-
To: Common-Lisp%su-ai@usc-ecl
Subject: Function objects
The Laser Edition of the Common Lisp Reference Manual is inconsistent in
its treatment of functions. This inconsistency is due to confusion
between the name of a function and the actual function object. This
confusion has been around for a long time, and is manifested in many
Lisp implementations where the name of a function object and the object
itself are the same. To quote from the Standard Lisp Report: "FUNCTION
is like QUOTE but its argument may be affected by compilation."
First, we need to state what we mean by a function object. The
definition of the FUNCTIONP data type predicate says that it
"is true if its argument is suitable for applying to arguments, using
for example the FUNCALL or APPLY function."
The definition of APPLY states that its argument
"may be a compiled-code object, or a lambda expression, or a symbol; in
the latter case the global functional value of that symbol is used."
(Let's ignore compiled-code objects for the time being; we'll get back
to them later.) This is the definition which confuses the name (symbol
or lambda expression) and the function object. Conflicting with this
definition is the Functions section of the Progam Structure chapter
(Section 5.2, p. 42). It states that
"Lambda-expressions and symbols as names of functions can appear only as
the first element of a function-call form, or as the second element of
the FUNCTION special form."
The definition of the FUNCTION special form, where FN is the second
element of the form, states that
"if FN is a symbol, the functional value of the variable whose name is
that symbol is returned. If FN is a lambda expression, then a lexical
closure is returned."
Notice that the definition of APPLY doesn't even mention lexical
closures, yet these are the things which are produced by the FUNCTION
special form, which is presumably the preferred means of obtaining a
suitable object to use as an argument to APPLY!
The key to understanding all of this is to realize that the CAR of a
Lisp form (ignoring macros and special forms) is not "not evaluated," in
fact it is a function name which is evaluated to produce a function
object. In Scheme this evaluation is the same as that used to produce
function arguments, i.e. the function EVAL. Common Lisp must use a
different algorithm, because it permits symbols to have distinct
variable and function values. The function which implements this
algorithm is not mentioned in the Common Lisp manual. In fact I don't
know of any Lisp implementations which provide it; it is usually
open-coded (sometimes a no-op!) within EVAL. For the sake of
discussion, let's call it FEVAL. In fact the one we are most interested
in is *FEVAL, analogous to *EVAL, since this function must use the
current lexical environment in its evaluation process.
Evaluation of a form which represents an ordinary function call is thus:
FEVAL the CAR of the form, EVAL all the other elements of the list, call
the result of FEVAL with the EVALed arguments. FEVAL is useful to
produce a function object which will not be called immediately. The
FUNCTION special form says in effect: use FEVAL instead of EVAL to
produce this argument. Conversely, EVAL is also useful in producing
function objects. FUNCALL allows normal argument evaluation to return
a function object to be called. Note that neither FUNCTION nor
FUNCALL is needed in Scheme precisely because EVAL and FEVAL are the
same.
FEVAL is a very simple function. If its argument is a lambda
expression, it returns a closure of the expression over the lexical
environment. If it is a symbol, the "functional variable" value of the
symbol in the lexical (or global) environment is returned. Anything
else is an error. As an upward-compatible extension, function specs as
provided in Zetalisp, such as (:PROPERTY FOO BAR), are treated
essentially the same as symbols. They simply specify a place from which
to fetch a function object.
The semantics of compiled-code objects have not been described
extensively in the Common Lisp manual. They are mentioned in the
spurious definition of APPLY above, which might lead one to think of
them as being "like lambda expressions, only faster." In fact the only
sensible interpretation of a compiled-code object is "like FEVAL of a
lambda expression, only faster." In other words, anything a lexical
closure can do, a compiled-code object can do, except that the structure
selector functions defined below would only be for lexical closures.
This should be stated explicitly in the manual in the data type section.
The argument to APPLY (and FUNCALL) can be a compiled-code object or a
lexical closure; anything else is an error. A language standard which
considers symbols or lambda expressions to be functions is perpetuating
the confusion described above.
To acheive the effect of using a symbol as a function as described above
(and currently implemented in Zetalisp, for example), that is, using the
global functional value at the time it is called, one must use a closure
which calls the function, e.g. to give BAR as a functional argument to
FOO, where BAR's definition may change between the call to FOO and the
FUNCALL of its functional argument, use:
(FOO #'(LAMBDA (X) (BAR X))) ;BAR is a function of one argument
instead of
(FOO 'BAR)
In general, if the number of arguments is unknown:
(FOO #'(LAMBDA (&REST X) (APPLY #'BAR X)))
Or, if you really mean the global function value, not the lexical:
(FOO #'(LAMBDA (&REST X) (APPLY (SYMBOL-FUNCTION 'BAR) X)))
The current language definition does not provide either a function which
takes a lambda expression and a lexical environment and returns a
lexical closure (*FEVAL) or functions to extract these components from
an existing lexical closure. These aren't strictly necessary, but
without them many useful parts of a programming environment must be
written non-portably. For example, GRINDEF is impossible in portable
Common Lisp, since SYMBOL-FUNCTION must return either a lexical closure
or a compiled-code object. A structure editor which can redefine a
function requires both selector functions and the constructor function,
since it must create a new closure with the modified function body.
I recommend that lexical environments be included in the language as
first-class objects. *EVAL and EVALHOOK would then be defined to take
exactly two arguments. ENCLOSE (*FEVAL restricted to lambda
expressions) takes a lambda expression and a lexical environment and
returns a lexical closure. CLOSURE-EXPRESSION and CLOSURE-ENVIRONMENT
take a lexical closure and return its components. The constant
NULL-ENVIRONMENT, the empty lexical environment, should be defined. The
structure of a lexical environment need not (indeed, should not) be
specified. These additions are not major and would aid immensely in
supporting a truly lexical Lisp.
∂03-Jun-83 1339 KMP@MIT-MC Another Ballot
Received: from MIT-MC by SU-AI with TCP/SMTP; 3 Jun 83 13:38:25 PDT
Date: 3 June 1983 16:32 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
Subject: Another Ballot
To: Fahlman @ CMU-CS-C
cc: Common-Lisp @ SU-AI
A1 Yes PARSE-INTEGER is OK.
A2 No I prefer that declarations be special forms. I would prefer to offer
PROCLAIM with no argument evaluation and *PROCLAIM as a subr form
such that (PROCLAIM form1 form2 ...) is the same as
(EVAL-WHEN (EVAL COMPILE LOAD) (*PROCLAIM 'form1 'form2 ...))
That is, the subr form should not be "implicitly" in any EVAL-WHEN.
I would like to keep the common, purely declarative, case simple.
A3 B I strongly prefer B. I believe it to be maximally consistent with
the rest of the Common-Lisp design. I also believe that current
Lisp Users' models best support this view.
I would also accept a hybrid B/C with syntax as per B, but with
case-insensitive lookup. I slightly prefer B to this, however.
I believe C is just barely acceptable, but I think this will do
very bad things to users' models. Many users take a long time to
understand what |...| and / are about already; I believe trying to
separate contexts where they can be used will add undue conceptual
overhead for novices.
I strongly oppose A as inconsistent with the case-retention rules for
the "other half" of symbols. I think novices would be confused silly
by this.
A4 Yes Consistency between VECTOR-PUSH,etc. and PUSH sounds good.
A5 Yes I like NTH-VALUE. NTH was zero based and people can live with that.
I find such an argument spurious.
A6 --- I have no strong feelings on this named structure primitives issue.
A7 Yes I strongly support this. Users read too much into the symmetry of
names SET and SETQ. In a lexical lisp, this is far more dangerous
than a dynamic lisp. ALAN should just type (SETQ #.+ ...) to the
read-eval-print loop.
A8 Yes I think (APPLY '(LAMBDA ...) ...) should be left undefined and
implementors might be free to support it as an implementation-
dependent upward compatible extension. This will save implementors
from having to take any immediate action, but leave Common Lisp
more flexibility later on. Users should be discouraged from doing
this.
A9 No If SVREF exists, then VREF maybe should exist for symmetry; otherwise,
it seems like SVREF should be SAREF instead ... Alternatively, SVREF
could be renamed VREF. I'm not sure any more what the full proposal
for arrays/vectors looks like any more. I'd rather defer this issue
until I can evaluate it more coherently.
A10 Yes Extra arg to MAKE-RANDOM-STATE sounds harmless and potentially useful.
A11 Yes Just this week I found the APPLYHOOK feature in the LispM and was
able to clean up some very ugly code which was trying to replace it.
The phrase "EVAL binds both *EVALHOOK* and *APPLYHOOK* to NIL
around calls to either of them." has a very nebulous "them" referent.
A12 No I like and use Destructuring LET a lot, but am sympathetic to peoples'
arguments that it is a data abstraction violation in general. I do,
however, agree with Weinreb's comments on DLET and suggest that he
propose this DESTRUCTURING-BIND primitive as an alternative.
A13 Yes Flush FIND-EXTERNAL-SYMBOL in favor of FIND-SYMBOL with extra value.
The extra value would be needed in any case to disambiguate the case
of FIND-SYMBOL of "NIL" ...
A14 Yes MULTIPLE-VALUE => MULTIPLE-VALUE-SETQ
A15 Yes Add ARRAY-RANK-LIMIT, etc. Even if these were the same values
everywhere, having people compare to symbolic names would be good.
A16 No This has certain SET/SETQ confusions about it that make me very
uncomfortable. The issue of "scoped" macros doesn't now occur but
might some day and I worry that if arg1 to SET-MACRO is ever anything
besides 'something, it may be hard to statically resolve in a useful
way. The minimal change that would make me happy is to call it
SETQ-MACRO or MACRO-SETQ or some such, but all in all, I'd rather
just flush this proposal.
MACRO has other problems (like it's a pain for programs like ATSIGN
and EMACS which may not realize it defines something). Why not just
change its name to DEFINE-PRIMITIVE-MACRO. I think that would
adequately discourage its use by novices while not introducing the
SET/SETQ problem I mentioned about above.
A17 --- This sounds superficially like a good idea, but I have done no
significant programming in such areas so can't adequately evaluate
the efficiency implications or the effect on the compiler of not
being able to predict an exact datatype returned from one of these
functions (potentially important on general purpose hardware). So
I'll abstain and hope you others know what you're doing.
∂03-Jun-83 1403 @MIT-MC:Cassels@SCRC-TENEX Functions for taking apart floating-point numbers
Received: from MIT-MC by SU-AI with TCP/SMTP; 3 Jun 83 14:03:15 PDT
Received: from SCRC-CONNECTICUT by SCRC-SPANIEL with CHAOS; Fri 3-Jun-83 14:48:00-EDT
Date: Friday, 3 June 1983, 14:47-EDT
From: Robert A. Cassels <Cassels at SCRC-TENEX>
Subject: Functions for taking apart floating-point numbers
To: Common-Lisp at su-ai
Proposal: Remove @f[float-exponent] and @f[float-integer-exponent], and
return those numbers as the second values from
@f[float-significand] and @f[float-integer-significand].
This would serve to make these functions more similar to the division
functions, and emphasize the close relationship between the values. It
also leads to slightly improved efficiency of implementation,
particularly on systems with unnormalized (or denormalized) numbers, and
those with "non-numeric" floating-point values [IEEE floating-point,
anyone?] which must be checked. (I'm assuming that when one value is
wanted, the other is almost always wanted also.)
In addition, the comment:
@Implementation{The typical implementation will be such that
the difference between the values returned by @f[float-integer-exponent]
and @f[float-exponent] will be equal to the number of internal-floating-radix
digits used to represent the significand. However, @clisp programs should
not assume this to be the case.}
should either be removed or expanded to note that this is not true of
unnormalized or denormalized numbers.
---------
Proposal: Add new functions @f[float-digits] and @f[float-precision].
@f[(float-digits float)] would return the number of @f[(float-radix
float)] digits used in the representation of a floating-point number.
(Including the "hidden bit", if any.) For most implementations, this is
really a property of the type of @f[float].
@f[(float-precision float)] would return the number of significant
@f[(float-radix float)] digits present in @f[float].
@Implementation{For implementations using only normalized numbers, these
functions would be identical. @f[(- (float-digits float) (float-precision
float))] would reflect the degree of denormalization of @f[float].}
These functions are needed to simplify the movement of floating-point
numbers from one implementation to another. They are also needed to
convert numbers from one base to another in a way which reflects the
precision (doesn't print bogus digits). @f[float-digits] could be
computed for most implementations by @f[(- (float-exponent 1.0)
(float-exponent single-float-epsilon))] or something like that. But
making it a function seems cleaner than some sort of typecase.
---------
Proposal: Require the result of @f[float-integer-significand] to
reflect the precision of the floating-point number.
Currently, @f[float-integer-significand] is only required to satisfy the
identity relating it to @f[float-integer-exponent]. That allows the
result to be scaled by various powers of the radix, so long as the
exponent is adjusted appropriately. So if @i[b] is @f[(float-radix float)]
and @i[p] is @f[(float-precision float)], the result of
@f[(float-integer-significand float)] for non-zero @f[float] should be
between @f[(expt b p)] (exclusive) and @f[(expt b (1- p))] (inclusive).
---------
Proposal: Clarify the result of @f[(float-sign 0.0)], @f[(float-sign
-0.0)].
The possibility of signed zeros needs to be addressed. Presumably
@lisp
(float-sign 0.0) @EQ 1.0
(float-sign -0.0) @EQ -1.0
@endlisp
∂03-Jun-83 1431 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN Ballot A
Received: from MIT-MC by SU-AI with TCP/SMTP; 3 Jun 83 14:30:40 PDT
Received: from SCRC-COLLIE by SCRC-TENEX with CHAOS; Fri 3-Jun-83 17:29:13-EDT
Date: Friday, 3 June 1983, 17:27-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Ballot A
To: Common-Lisp@SU-AI
A1. PARSE-INTEGER Yes
A2. PROCLAIM is a function Yes
A3. Package name lookup none of the above
I agree that making the syntax of the package-name part of a qualified
name exactly like the syntax of the symbol-name part is an improvement,
and I'm willing to give in and allow vertical bars here. Note that this
syntactic equivalence applies both to READ and to PRINT.
Note that package names are given in three essentially different contexts:
As prefixes in qualified names of symbols
As arguments to functions that take a package object or name, e.g. USE-PACKAGE
As the name when creating a package, e.g. MAKE-PACKAGE first argument.
I am unhappy about any scheme that involves a string-based user interface
to something that uses case-sensitive lookup. I have two proposals, the
first being preferred:
1) Package-name lookup is case-insensitive; you cannot have two
distinct packages whose names differ only in case. The case of
the name given to MAKE-PACKAGE is remembered, thus if it is not
all upper-case the package name will contain escape characters
when printed in a qualified name.
1a) An acceptable variant says that MAKE-PACKAGE calls STRING-UPCASE
if given a string (but not if given a symbol) as the name.
2) Package-name lookup is case-sensitive but the user interface is in
terms of symbols rather than strings; thus MAKE-PACKAGE, USE-PACKAGE,
EXPORT, etc. demand symbols as their package-name arguments. These
symbols are compared with SAMEPNAMEP, not EQ, thus it doesn't matter
what package they are in. The serious problem with this is: does
PACKAGE-NAME return a symbol or a string, and if it returns a symbol,
what package is the symbol in, or is it uninterned?
A4. VECTOR-PUSH arg order Yes
A5. NTH-VALUE Mildly in favor
A6. Named-structure primitives Neutral
I don't care whether the named-structure primitives are considered to
be part of the language or part of defstruct, i.e. whether they appear
in the White Pages or in the Implementor's Guide to Installing Defstruct.
I am opposed to the :NAMED argument to MAKE-ARRAY and MAKE-VECTOR appearing
in the white pages, although in fact it will exist in both Symbolics and Spice
Common Lisp dialects.
A7. Flush SET, SETF None of the above
I favor the way Steele had it in the manual last time I looked, which
was that SET is retained due to the grandfather clause, and its frequent
usefulness, whereas FSET is removed due to confusion with SETF and lack
of frequent usefulness.
A8. (apply '(lambda ...)) is an error No
I am opposed to this because it would be a break with the past whose
implications are not well-understood. Later we can decide it is bad
style and discourage it, if we like.
I think there are good reasons to allow a function name to stand for
a function object, when the function object contains no free lexical
references. If there are free lexical references, it is an error.
The NIL interpreter seems to do a nice job of warning about this error.
It is already noted in the manual that APPLY with a symbol as the first
argument looks up the functional value of that symbol in the global
environment, not the caller's environment. (Of course, (APPLY 'FOO...)
is exactly analogous to (EVAL 'FOO).) Even the latest version of
the manual forgets to say this for FUNCALL, but surely FUNCALL and APPLY
are supposed to be consistent.
A9. Add VREF Neutral
A10. Integer seed for MAKE-RANDOM-STATE Yes
Stress that this gives you a -repeatable- sequence of random numbers,
and that the implementation makes "an effort" not to give the same
sequence for different seeds.
A11. Add APPLYHOOK Yes
A12. Add DLET No
I think we should have destructuring, but not with this name and
not with the syntax of LET. By voting against this it is incumbent
on me to propose an alternative; I'll try to send out a proposal
early next week. There are more issues than recognized by the
simple proposition that DLET be added.
I think it is probably a good idea to defer destructuring until the
second edition of the manual because there is probably going to be a
substantial amount of discussion. For now, let's have it only in
DEFMACRO where the issues are very clear.
A13. Two values from INTERN, FIND-SYMBOL Yes
Flush FIND-EXTERNAL-SYMBOL
A14. MULTIPLE-VALUE-SETQ Neutral
If it is called ...-SETQ, it must accept any even number of
subforms, not just 2.
A15. Implementation limit constants Yes
I agree with DLW and BSG about putting a floor under these.
The constants are still valuable, e.g. for checking whether a program
will work in an implementation without exhaustively testing all paths
through the program. If you want suggestions for the floors, I'll
suggest 3 dimensions, 50 arguments, and 10 values. The actual hard
limits in my implementations are 7, 63, and 10 (easily raised to 63)
in the LM-2, and something higher in the 3600 (7, 255, and 255 except
that there are probably other limits that come into play a little below
255).
Is the limit on number of arguments different for functions with
&REST or &KEY than for fixed-maximum functions? Does the limit on
number of arguments apply to the length of the last argument to APPLY?
A16. Flush MACRO Yes, but
I agree with EAK that it should be SETF of MACRO-FUNCTION.
My objection to MACROP being a ps****predicate (i.e. returning
the expander function), was that people should not be allowed to
call that function directly; only EVAL and MACROEXPAND-1 may call it.
This was for macro memoization and in the hope that checking of the
length of the form could be centralized rather than done separately
by each expander function. These aren't strong enough reasons to
turn down the proposal, especially since we have *MACROEXPAND-HOOK*
now. Checking of the length of the form is really subsumed into
checking of the syntax of the form, and needs to be done separately
by each expander function, I now believe.
A17. Gaussian rationals No vote
It is already the case that (integerp 4/2) is true. There was a slight
braino about this somewhere in the Laser manual.
Having Gaussian rationals behave as an extension of the real rationals
seems superficially plausible, but I don't consider myself competent to
evaluate the implications. Let me ask the $64 question: will the result
of any function, other than type-checking functions and transcendental
functions, be affected by this change (i.e. are there other functions
that treat complex numbers on the real line different from real numbers)?
∂03-Jun-83 1452 HEDRICK@RUTGERS.ARPA Re: Another ballot
Received: from RUTGERS by SU-AI with TCP/SMTP; 3 Jun 83 14:51:05 PDT
Date: 3 Jun 83 17:52:01 EDT
From: Dir LCSR Comp Facility <HEDRICK@RUTGERS.ARPA>
Subject: Re: Another ballot
To: Fahlman@CMU-CS-C.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: Message from "Scott E. Fahlman <Fahlman@CMU-CS-C>" of 3 Jun 83 02:27:00 EDT
A1. Yes, do PARSE-INTEGER. But no pound-signs or other hair, please.
A2. I think I am opposed to the details of the new PROCLAIM. I agree
with most of what is proposed, but I do not like the idea of an
implicit EVAL-WHEN, at least if I understand what is meant. I
would like PROCLAIM to be evaluated in exactly the same way as
DEFUN. That is, if you type it at the top level of Lisp, or it
is at the top level of a file, it would work in the expected
way. As I understand it, you are proposing that a PROCLAIM
could occur in a random place in the middle of code, and it
would still happen at COMPILE or LOAD time. I think this is a
bad idea. The whole idea of restricting DECLARE to the
beginning of blocks was to minimize this kind of thing.
A3. We can live with anything that you can implement, but would prefer
B, to treat the package part just like the symbol part. MUCH
easier for users to remember.
A4. Yes, fix VECTOR-PUSH and VECTOR-PUSH-EXTEND.
A5. No, we don't need more MV mechanisms. As always, I propose to
simply MV's further by removing them.
A6. No, I am satisfied with an almost-transportable DEFSTRUCT.
A7. No, do not remove SET. While we are at it, CONS seems like an
unnecessary relic. It is after all a special case of a
structure....
A8. No, do not make it an error to do (APPLY '(LAMBDA ... That is,
don't do just that. However I agree completely that the whole
issue of what is a function object needs further thought. If
a complete analysis of this results in (LAMBDA not being a
function object and thus not allowing APPLY on it, I am willing
to accept that. I suspect that it is too late to do such an
analysis for this release of Common Lisp.
A9. Abstain on VREF.
A10. Yes, allow a seed in MAKE-RANDOM-STATE.
A11. My concern with APPLYHOOK is whether we are ready to standardize
that hook. If all of the implementors and potential
implementors agree that these are the right hooks, then
by all means. I defer to the Spice people on this, since we
are using their evaluator.
A12. Yes, allow simple destructuring. Do not destructure the family cat.
A13. No, do not make INTERN return multiple values. I am willing to
allow it for FIND-SYMBOL, however.
A14: Yes, that name seems reasonable. Would you consider using
MV-SETQ, etc.? While I am just as happy to discourage the use
of all MV primitives, do we really want primitives with names
that are that long?
A15: In general I accept the proposal on bounds. I think some
implementations might be able to live with arrays with a small
maximum rank. However I do not believe that this is true for
arguments for functions. I agree that it is a pain to
implement large numbers of arguments for functions. I know.
It has caused us real hassles. Nevertheless I believe it is
necessary. I am willing to let implementors cop out on
array ranks if they want to, but not on arguments. I believe
that the only limits on number of arguments should be those
imposed by the size of memory, stack space, etc. It is bad
enough to have arbitrary limits in Pascal. In a language
like Lisp it is unforgiveable. We probably need to set an
actual number as the minimum maximum number of arguments. The
number must be set large enough to make it impossible for
an implementation to get away with any of the easy solutions,
and small enough that we can still implement CLISP on a micro.
By the way, would you allow us to set CALL-VALUES-LIMIT to 1?
A16. OK, do what you want with MACRO.
A17. Yes, reduce all numbers to their simplest form (but not floating
point to integers...)
-------
∂03-Jun-83 1727 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN PROCLAIM and implicit EVAL-WHEN
Received: from MIT-MC by SU-AI with TCP/SMTP; 3 Jun 83 17:27:23 PDT
Received: from SCRC-COLLIE by SCRC-TENEX with CHAOS; Fri 3-Jun-83 20:25:25-EDT
Date: Friday, 3 June 1983, 20:24-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: PROCLAIM and implicit EVAL-WHEN
To: common-lisp@SU-AI
In-reply-to: The message of 3 Jun 83 17:52-EDT from Dir LCSR Comp Facility <HEDRICK at RUTGERS.ARPA>
Date: 3 Jun 83 17:52:01 EDT
From: Dir LCSR Comp Facility <HEDRICK@RUTGERS.ARPA>
A2. I think I am opposed to the details of the new PROCLAIM. I agree
with most of what is proposed, but I do not like the idea of an
implicit EVAL-WHEN, at least if I understand what is meant. I
would like PROCLAIM to be evaluated in exactly the same way as
DEFUN. That is, if you type it at the top level of Lisp, or it
is at the top level of a file, it would work in the expected
way. As I understand it, you are proposing that a PROCLAIM
could occur in a random place in the middle of code, and it
would still happen at COMPILE or LOAD time. I think this is a
bad idea. The whole idea of restricting DECLARE to the
beginning of blocks was to minimize this kind of thing.
I guess this wasn't explained very well; probably my fault. The implicit
EVAL-WHEN is to make PROCLAIM be evaluated in exactly the same way as DEFUN.
In other words, when the compiler sees PROCLAIM "at top level" it evaluates
it at compile time, rather than just pushing the form through into the "fasl"
file to be evaluated at load time. There are a bunch of functions and special
forms with this property, that the compiler knows to handle them at compile
time; hopefully the next edition of the manual will list them.
Precisely what "at top level" means seems to be still under discussion. But
clearly it means at least real top-level, inside PROGN, and inside COMPILER-LET.
It means inside some flavors of EVAL-WHEN too. But it doesn't mean at a
random place in the middle of code; there PROCLAIM is just a function like
any other.
By the way, would you allow us to set CALL-VALUES-LIMIT to 1?
No, for obvious reasons (there are functions in the manual that are
defined to return two values).
∂03-Jun-83 1851 Walter.VanRoggen@CMU-CS-A Another ballot
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 3 Jun 83 18:50:47 PDT
Date: 3 June 1983 2145-EDT (Friday)
From: Walter van Roggen <Walter.VanRoggen@CMU-CS-A> (C410WV50)
To: Fahlman@cmu-cs-c
Subject: Another ballot
CC: Common-Lisp@SU-AI
Message-Id: <03Jun83.214553.WV50@CMU-CS-A>
A1: yes. But with PARSE-INTEGER to help read data, do we really
need *READ-BASE* so much?
A2: ok
A3: option B. Lisp syntax is complex enough as it is. (perhaps a
surprising thing to say, even discounting FORMAT.)
A4: yes
A5: ok, 0 based
A6: no
A7: yes, at least get rid of FSET, preferably both. I'd also like to see
SETF renamed to SET, but that seems too much to ask for now.
A8: yes
A9: ok, though I'd prefer getting rid of CHAR and BIT as well
A10: yes, though what arguments should MAKE-RANDOM-STATE take then?
A11: ok
A12: yes iff DEFMACRO has it.
A13: ok
A14: yes
A15: ok, but rename CALL-VALUES-LIMIT to MULTIPLE-VALUES-LIMIT. We must
agree on lower bounds for these values. There should be no bound on
the number of arguments to a function, only on the number of named
ones.
A16: yes
A17: yes
---Walter
∂03-Jun-83 1913 GSB@MIT-ML ballot A
Received: from MIT-ML by SU-AI with TCP/SMTP; 3 Jun 83 19:13:25 PDT
Date: 3 June 1983 22:15 EDT
From: Glenn S. Burke <GSB @ MIT-ML>
Subject: ballot A
To: Fahlman @ CMU-CS-C
cc: common-lisp @ SU-AI
A1. Add parse-integer.
Yes.
A2. Proclaim.
Yes.
A3. [Package names]
I could live with b or c. I have no strong objection to either.
A4. vector-push arg order.
Yes, fix it.
A5. Add KMP's (NTH-VALUE n form)
No objection if it is zero origined.
A6. defstruct primitives
I don't really care. The proposal was to supply an alternative
to named arrays, which i do not approve of in the white pages
as a mechanism for defining typed objects.
A7. eliminate SET and FSET
I am fairly neutral on this.
A8. (apply '(lambda ...) ...)
It should either be invoked in a null lexical environment, or be
totally illegal. In NIL, I have experimented with it both being
invoked in a null environment, and being invoked in the "current"
environment. The latter makes (mapcar '(lambda ...) ...) work
as a Maclisp user might expect, but is totally ridiculous otherwise.
Also, I do not see how it can be tractable to interpret it as if it
were #'(lambda ...), because by the time you see it you have lost
the context.
A9. Propose that we reinstate VREF.
Shucks, i had just written documentation stating that this was
obsolete. I don't really care. I would prefer to have primitives
to access the simple array types.
A10. Add an optional integer seed to MAKE-RANDOM-STATE.
Yes.
A11. Propose that we adopt the APPLYHOOK feture, as specified by Moon.
Yes.
A12. Add a simple form of destructuring LET macro.
Not as proposed.
I would like a destructuring primitive which provides exactly
the functionality defmacro provides, including &mumbles. It
should not be LET based; my experience with destructuring LET
is that (besides grossness with LET*) the extra parentheses
needed by LET syntax make it unreadable. The NIL compiler defines
(defmacro debind-args (pattern call-form &body body) ...).
This is also used by the interpreter.
A13. A modification to INTERN and FIND-SYMBOL
This sounds reasonable.
A14: Proposed by KMP that we rename MULTIPLE-VALUE to MULTIPLE-VALUE-SETQ.
Can we shorten these to MV-SETQ and MV-BIND? Instead of
(multiple-value-setq (a b c) ...) it will be tempting to abbreviate to
(setf (values a b c) ...), although i guess that is not supported.
A15: Implementation limits
Yes we should have constants with the values of those limits,
but No, we SHOULD specify certain minimums within which portable
code may blithely run correctly.
A16. Guy proposes that we get rid of MACRO
Yes, but (setf (macro-function ...) ...).
A17. Reduction to canonical form
For rationals, yes, definitely.
For the complex case i am not so sure. I guess i will defer to
others on this, but i feel uncomfortable with it.
∂03-Jun-83 2050 GJC@MIT-ML Destructuring
Received: from MIT-ML by SU-AI with TCP/SMTP; 3 Jun 83 20:49:55 PDT
Date: 3 June 1983 23:51 EDT
From: George J. Carrette <GJC @ MIT-ML>
Subject: Destructuring
To: COMMON-LISP @ SU-AI
I have a note talking about reasons for a destructure feature if
anybody wants me to sent it to them. Suffice it to say that destructuring
is used heavily in the evaluator, compiler, and macrology of NIL, and it
has saved a lot of CAR/CDR'ing and control structure. The name I suggest
for the special form is DESTRUCTURE. It isn't very difficult to
implement entirely in lisp, with no restrictions on keyword placement etc.
;; Here is an example call:
(defknown si:examine-byte (form)
(destructure form
(p &optional (i 0))
...)))
;; Which is equivalent to:
(defknown si:examine-byte (form)
(dspread&apply (lambda (p i) ...) '(p &optional (i 0)) form))
;; Which is a pretty good hint of how it is implemented in NIL. -GJC
∂03-Jun-83 2052 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN Functions for taking apart floating-point numbers
Received: from MIT-MC by SU-AI with TCP/SMTP; 3 Jun 83 20:52:10 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Fri 3-Jun-83 23:51:49-EDT
Date: Friday, 3 June 1983, 23:50-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Functions for taking apart floating-point numbers
To: Common-Lisp@su-ai
In-reply-to: The message of 3 Jun 83 14:47-EDT from Robert A. Cassels <Cassels at SCRC-TENEX>
Date: Friday, 3 June 1983, 14:47-EDT
From: Robert A. Cassels <Cassels at SCRC-TENEX>
Proposal: Remove @f[float-exponent] and @f[float-integer-exponent], and
return those numbers as the second values from
@f[float-significand] and @f[float-integer-significand].
I think this was turned down last year, but I don't remember why. It sounds
reasonable to me, except that one would probably want to choose better names
for the two functions. I'm in favor of it.
Proposal: Add new functions @f[float-digits] and @f[float-precision].
I don't understand the need for both of these. It sounds like float-precision
is the only one you actually need; float-digits returns the same answer except
for certain exceptional numbers.
Proposal: Require the result of @f[float-integer-significand] to
reflect the precision of the floating-point number.
This sounds reasonable. The main competing proposal is that it return
a result "normalized to the right" by removing trailing zeros. Your
proposal seems slightly preferable to that.
Proposal: Clarify the result of @f[(float-sign 0.0)], @f[(float-sign
-0.0)].
I think this is just a clarification, since the manual indicates that
float-sign with one argument never returns zero even if the argument is zero.
∂03-Jun-83 2115 Guy.Steele@CMU-CS-A Re: typep of array
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 3 Jun 83 21:15:09 PDT
Date: 4 June 1983 0012-EDT (Saturday)
From: Guy.Steele@CMU-CS-A
To: David A. Moon <Moon%SCRC-TENEX@MIT-MC>
Subject: Re: typep of array
CC: common-lisp@SU-AI
In-Reply-To: "David A. Moon's message of 3 Jun 83 01:13-EST"
Yep, that's a problem all right. More abstractly, what you want
is the union of all array types over various suitable finite
sets (of which there are potentially infinitely many, though any given
implementation will have only a finite number). Unfortunately,
the notation (ARRAY INTEGER) means not a union of the arrays over{
infinitely many finite domains, but the array type over the union
of the infinitely many finite domains.
--Guy
∂03-Jun-83 2124 Guy.Steele@CMU-CS-A Reply to ballot A
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 3 Jun 83 21:23:49 PDT
Date: 4 June 1983 0021-EDT (Saturday)
From: Guy.Steele@CMU-CS-A
To: common-lisp@SU-AI
Subject: Reply to ballot A
I favor all proposals except as noted otherwise below:
2, 4, 9, and 13 are okay by me, but I don't feel strongly about them.
I oppose 5, 6, 8, 10, and 12.
For question 3, I much prefer option (b).
∂03-Jun-83 2141 Guy.Steele@CMU-CS-A Addendum to my answers on ballot A
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 3 Jun 83 21:41:19 PDT
Date: 4 June 1983 0039-EDT (Saturday)
From: Guy.Steele@CMU-CS-A
To: common-lisp@SU-AI
Subject: Addendum to my answers on ballot A
I was so busy being terse that I forgot these notes:
For question 7, I favor flushing FSET and retaining SET. While we're
at it, let's reinstate ASET.
Regarding MAKE-RANDOM-STATE, I oppose the ability for the user to
provide an integer seed. The laser edition specifies that an argument
of T will cause MAKE-RANDOM-STATE to initialize the new state object
in a "random" manner. The reason for this specification is that the
implementor knows how many bits of state are in the state object
and the user does not, so the user can't know whether his seed
is "random enough"; the implementor can do a much better job of
randomizing the state. If the user wants to be able to make
several random-state objects that all begin with the same seed,
he is advised to call (MAKE-RANDOM-STATE T) and then make
several copies of the result. The object may be written out to
a file and read back in (this is specified precisely so that
you can get consistent random behavior in separate sessions).
∂03-Jun-83 2148 Guy.Steele@CMU-CS-A Array rank
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 3 Jun 83 21:48:00 PDT
Date: 4 June 1983 0047-EDT (Saturday)
From: Guy.Steele@CMU-CS-A
To: common-lisp@SU-AI
Subject: Array rank
Actually, my memory differs from DLW's; I thought McCarthy suggested 63.
Yes, that number is causing flak. I bet 7 would be acceptable.
Indeed, if you write a portable program that has a function of 93 arguments
and try to run it on an implementation that supports only 92 you will
lose. If you write a portable program that does an FFT on a ten-gigabyte
array and try to run it on an 8086, you will also lose. I'm not sure
what is the best thing to write into the standard, which is why
I wanted to re-raise the issue.
--Guy
∂03-Jun-83 2230 Guy.Steele@CMU-CS-A pervasiveness of declarations
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 3 Jun 83 22:30:23 PDT
Date: 4 June 1983 0130-EDT (Saturday)
From: Guy.Steele@CMU-CS-A
To: common-lisp@SU-AI
Subject: pervasiveness of declarations
- - - - Begin forwarded message - - - -
Received: from CMU-CS-PT by CMU-CS-A; 4 Jun 83 01:10:43 EDT
Received: from MIT-MC by CMU-CS-PT; 4 Jun 83 01:07:44 EDT
Date: 4 Jun 1983 0110-EDT
From: RMS%MIT-OZ@MIT-MC
Subject: Re: Simplifying local declarations
To: Guy.Steele@CMU-CS-A
In-Reply-To: Your message of 4-Jun-83 0031-EDT
I believe all declarations should be pervasive.
I allow arbitrary declarations that users can
look at in their macro definitions; these are all pervasive.
So my documentation would have to say,
"all declarations are pervasive except for FOO and BAR,"
which I think is unclean. I'm sure I can manage to implement
nonpervasive declarations, though it is much simpler this way,
but I would be ashamed to admit it to the users.
Anyone who really really wants a declaration not to be pervasive
can do
(LET (vars)
(DECLARE (FOO ..))
(PROGN
(DECLARE (UNFOO ...))
FOO not in effect here))
This is good enough for macros that may have to pay attention to this
in order to work right in all cases. I would not expect
hand-written code to ever need this.
What advantage is there, ever, to a nonpervasive declaration?
It may be that this issue is moot for me now. The only declarations
that matter on the Lisp machine are SPECIAL and UNSPECIAL.
If both of these are pervasive, I can say all declarations are
pervasive because I will just ignore the others anyway.
Regardless of what I do, making them all pervasive will still
simplify your own design.
I am disturbed to find out that this is not even being
considered, at least according to the message you sent me.
What do I have to do? I have explained it at least twice before.
Each time, when I inquired after a period of time that I thought
might suffice to consider the idea, I found it had not been
considered and you had forgotten what I said.
I hope you will at leat save this message so you will not
have to ask me again "what is it you are suggesting for declarations?"
Wrt PROCLAIM:
I have no opinion on this. I can implement PROCLAIM easily enough.
Of course, I am still going to support global use of DECLARE.
-------
- - - - End forwarded message - - - -
∂03-Jun-83 2256 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN Addendum to my answers on ballot A
Received: from MIT-MC by SU-AI with TCP/SMTP; 3 Jun 83 22:56:24 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Sat 4-Jun-83 01:57:53-EDT
Date: Saturday, 4 June 1983, 01:56-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Addendum to my answers on ballot A
To: Guy.Steele%CMU-CS-A@SU-DSN
Cc: common-lisp@SU-AI
In-reply-to: The message of 4 Jun 83 00:39-EDT from Guy.Steele at CMU-CS-A
Date: 4 June 1983 0039-EDT (Saturday)
From: Guy.Steele@CMU-CS-A
While we're at it, let's reinstate ASET.
ASET was flushed because it uses left-to-right data motion, whereas everything
else in Common Lisp uses right-to-left data motion. Let's ignore the fact
that I think ASET is right and everything else is wrong, and not put it back in.
Regarding MAKE-RANDOM-STATE, I oppose the ability for the user to
provide an integer seed. The laser edition specifies that an argument
of T will cause MAKE-RANDOM-STATE to initialize the new state object
in a "random" manner. The reason for this specification is that the
implementor knows how many bits of state are in the state object
and the user does not, so the user can't know whether his seed
is "random enough"; the implementor can do a much better job of
randomizing the state. If the user wants to be able to make
several random-state objects that all begin with the same seed,
he is advised to call (MAKE-RANDOM-STATE T) and then make
several copies of the result. The object may be written out to
a file and read back in (this is specified precisely so that
you can get consistent random behavior in separate sessions).
This argument would be more persuasive if there was a way provided
to copy a random-state. There is no way to do it that doesn't involve
I/O to a temporary file or a string.
∂03-Jun-83 2302 Guy.Steele@CMU-CS-A Copying a random-state
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 3 Jun 83 23:02:17 PDT
Date: 4 June 1983 0200-EDT (Saturday)
From: Guy.Steele@CMU-CS-A
To: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Copying a random-state
CC: common-lisp@SU-AI
In-Reply-To: "David A. Moon's message of 4 Jun 83 00:56-EST"
If you give a random-state to MAKE-RANDOM-STATE, it will return a copy.
I really did think all this out! Maybe an example is needed.
--Guy
∂03-Jun-83 2302 ALAN@MIT-MC Gaussian rationals
Received: from MIT-MC by SU-AI with TCP/SMTP; 3 Jun 83 23:02:11 PDT
Date: 4 June 1983 02:04 EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: Gaussian rationals
To: Common-Lisp @ SU-AI, Moon @ SCRC-TENEX
In-reply-to: Msg of 3 Jun 1983 17:27-EDT from David A. Moon <Moon%SCRC-TENEX%MIT-MC at SU-DSN>
Date: Friday, 3 June 1983, 17:27-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC at SU-DSN>
Having Gaussian rationals behave as an extension of the real rationals
seems superficially plausible, but I don't consider myself competent to
evaluate the implications. Let me ask the $64 question: will the
result of any function, other than type-checking functions and
transcendental functions, be affected by this change (i.e. are there
other functions that treat complex numbers on the real line different
from real numbers)?
I just carefully checked the Laser manual. I'm fairly certain that the
answer to your $64 question is: No.
However, I am not 100% convinced we are all talking the same language here.
Let me present a small dialog with a Common Lisp interpreter to demonstrate
the behavior I think we are proposing here:
(= (/ 4 2) 2)
T ;whatever (/ 4 2) returns, it must be
;indistinguishable from 2. [Except perhaps by
;using EQ? I guess that doesn't matter.]
(integerp (/ 4 2))
T ;Indistinguishable.
(eql (/ 4 2) 2)
T ;eql is defined to be = for numbers.
(= (complex 2 0) 4/2) ;Typing "4/2" should be just like typing "2".
T ;Again indistinguishable.
(+ #C(2/3 0) 1/3) ;Typing "#C(2/3 0)" is just like typing "2/3".
1
(integerp *)
T ;Whatever it is, it acts like an integer.
(nth (+ #C(0/69 7/7) (* 3 (complex (/ 4 6) -1/3))
'(zero one two three))
TWO
Now there is one issue that can go either way. Currently (according to
page 24 of Laser) the complex type and the rational type are DISJOINT. I
presume the idea is that the complex type is to consist of only those
numbers with non-zero imaginary part. Unfortunately this is a mis-use of
the mathematical term "complex", which is normally applied to a set of
numbers that INCLUDES the real numbers. The predicate COMPLEXP should
correctly be true of ALL Common Lisp number types, and should thus be
useless.
Better I think, would be to have a type named REAL, then where previously
you would have written (COMPLEXP ...), now you would write
(NOT (REALP ...)). I understand that there is a tendency in computer
languages to mis-use the word "real" to mean "floating point", but it's a
shame to introduce a new mis-use to cover for an old one.
[ BTW, I just chased all over the Laser manual trying to find where the
printed representation of complex numbers is set forth. I found it on
page 15, but I looked first in the Numbers chapter, and second in the
section of the I/O chapter titled "Printed representation...". All
plausible places to find such information...]
∂04-Jun-83 1041 fateman%UCBKIM@Berkeley Re: Gaussian rationals
Received: from UCB-VAX by SU-AI with TCP/SMTP; 4 Jun 83 10:41:37 PDT
Date: 4 Jun 83 10:42:57 PDT (Sat)
From: fateman%UCBKIM@Berkeley (Richard Fateman)
Subject: Re: Gaussian rationals
Message-Id: <8306041742.1846@UCBKIM.ARPA>
Received: by UCBKIM.ARPA (3.340/3.5)
id AA01846; 4 Jun 83 10:42:57 PDT (Sat)
Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.341/3.31)
id AA23288; 4 Jun 83 10:42:07 PDT (Sat)
To: @SU-AI:ALAN@MIT-MC, Common-Lisp@SU-AI, Moon@SCRC-TENEX
Is log(-1) an error if -1 is real, but i*pi if -1 is -1+0*i and "log"
means principal value? Previously I expressed my concern that
language designers should not build in to the language ithmetic
semantics or pragmatics that are controversial (or downright wrong:
I recall Basic has the result of an overflow be 0). I wish you luck.
∂04-Jun-83 1452 Guy.Steele@CMU-CS-A Volume of mail (trivia)
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 4 Jun 83 14:52:03 PDT
Date: 4 June 1983 1749-EDT (Saturday)
From: Guy.Steele@CMU-CS-A
To: common-lisp@SU-AI
Subject: Volume of mail (trivia)
If anyone cares, I received over 15000 (decimal!) lines of mail
in the last eight days. Essentially all of it was about Common LISP.
All this activity must imply that we are obviosuly (or at least
boviously) making substantial progress.
--Guy
∂04-Jun-83 1515 @MIT-MC:BSG%SCRC-TENEX%MIT-MC@SU-DSN Re: Volume of mail (trivia)
Received: from MIT-MC by SU-AI with TCP/SMTP; 4 Jun 83 15:14:43 PDT
Date: 4 Jun 1983 1814-EDT
From: Bernard S. Greenberg <BSG%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Re: Volume of mail (trivia)
To: Guy.Steele%CMU-CS-A@SU-DSN
cc: common-lisp@SU-AI
In-Reply-To: The message of 4 June 1983 1749-EDT (Saturday) from Guy.Steele@CMU-CS-A
Return-path: <Guy.Steele@CMU-CS-A>
Received: from MIT-MC by SCRC-TENEX with CHAOS; Sat 4-Jun-83 17:59:09-EDT
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 4 Jun 83 14:52:03 PDT
Date: 4 June 1983 1749-EDT (Saturday)
From: Guy.Steele@CMU-CS-A
To: common-lisp@SU-AI
Subject: Volume of mail (trivia)
If anyone cares, I received over 15000 (decimal!) lines of mail
in the last eight days. Essentially all of it was about Common LISP.
All this activity must imply that we are obviosuly (or at least
boviously) making substantial progress.
--Guy
---------------
As Doug Hofstadter ALMOST did in last month's column, you
should solicit from this list suggestions for decreasing the volume
of mail.....
-------
∂05-Jun-83 0130 ALAN@MIT-MC Gaussian rationals
Received: from MIT-MC by SU-AI with TCP/SMTP; 5 Jun 83 01:29:49 PDT
Date: 5 June 1983 04:31 EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: Gaussian rationals
To: Common-Lisp @ SU-AI, fateman @ UCBKIM
cc: Moon @ SCRC-TENEX
The point is that -1 and -1+0*i are the same number in any clear way of
thinking about the situation. To muddy the essential mathematics of the
situation (that the real rationals are a sub-field of the Gaussian
rationals) because of a user-interface issue (what users expect of certain
transcendental functions), is downright wrong.
I note that only a few transcendental functions have the potential
user-interface problem alluded to. By the nature of a field, no rational
function can escape from the reals. The GCD and LCM functions behave the
same way when restricted to the ring of integers as they do when their
domain is taken to be the ring of Gaussian integers. The NUMERATOR and
DENOMINATOR functions can consequentially be naturally extended to Gaussian
rationals. Various other miscellaneous functions like ABS and SIGNUM also
naturally extend to the complex case. Only a handful of transcendental
functions that have been traditionally expected to err when given certain
real arguments, could now be expected to yield a complex result.
The functions in question are: LOG, SQRT, ASIN, ACOS, ACOSH, and ATANH.
If anyone can find any more, they should speak up.
Not coincidentally, these are all functions that require the specification
of branch cuts. These are also all functions that deal in floating point
values. (Because floating point is the usual representation chosen for
transcendental numbers. Another unfortunate tradition, but not one we are
currently in a position to challenge.)
Not being a great fan of floating point, I don't like being in a position
where I have to suggest anything about these functions. However, since I
seem to be the one on the crusade to clean up the Gaussian rationals, I
feel I must make some proposal about what to do about these six functions.
I'll offer 4 possibilities:
1. Surprise everyone. In Common Lisp, these six functions are
complex-valued. People who expect (SQRT -1) to err are wrong. (I
would favor this myself, but I appreciate the arguments against it.)
2. These six functions are real-values only. Introduce six more
functions that have the full complex range. Nobody is surprised.
People who want complexes say (COMPLEX-SQRT -1). (Actually more
than six functions would need to be introduced; I presume we would
want a COMPLEX-ASINH to match COMPLEX-ACOSH etc.)
3. These six functions are complex-valued as in 1., and we additionally
introduce six new functions that are real-valued. People who want
(SQRT -1) to be an error, have to say (REAL-SQRT -1) instead.
(Again, more than six are really necessary.)
4. Since in all cases the answer is floating point, and since -1.0 and
#C(-1.0 0.0) really ARE different, define these functions to
return a complex result (in the questionable part of their domains)
ONLY if given a floating point complex argument. Thus (SQRT -1),
and (SQRT -1.0) are both errors, but (SQRT #C(-1.0 0.0)) is not.
To get the effect of the COMPLEX-SQRT function, you would write
something like (SQRT (COMPLEX X 0.0)). If we were to decide to do
this, then the next issue we get to haggle is what (SQRT #C(1 1))
does (since you can hardly regard 1+i a a "questionable" part of
the domain of SQRT!).
∂05-Jun-83 0810 FAHLMAN@CMU-CS-C Gaussian rationals
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 5 Jun 83 08:10:24 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 5 Jun 83 11:11:11 EDT
Date: Sun, 5 Jun 1983 11:11 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Alan Bawden <ALAN@MIT-MC>
Cc: Common-Lisp@SU-AI
Subject: Gaussian rationals
In-reply-to: Msg of 5 Jun 1983 04:31 EDT from Alan Bawden <ALAN at MIT-MC>
Not being a mathematician -- in fact, the only things I really believe
in are the integers from 0 through 1023, unless I have my shoes off
-- I feel that I'm way out of my depth here. I was one of the people
who didn't want complexes to be required at all, because I can't figure
out who around here is going to implement them. But whenever we do get
this installed, I would have no objection to Bawden's suggestion that we
do the mathematically right thing here. Anyone who is depending on
getting an error in some situation isn't writing portable Common Lisp
anyway, and if the user is expecting an error on (SQRT -1) and instead
gets #C(0 1), I see no problem there. The one problem I do see is that
we don't want users to take (SQRT 4.0) and get a complex, so we need a
rule that says that if you put a real in, floating or not, you get one
out if possible. But if the user who gets back a complex can simply say
to himself "Oh, that's an error if you're confined to the reals, but
here is what it looks like otherwise", then I've got no problem. If we
ever start distributing Common Lisp to grade schools we may want to put
in ways to turn off complexes (or even fractions), but that's a
special-purpose hack.
While we're talking about canonical forms, I would like to propose once
again that we require both halves of a complex to be of the same type:
rationals or one of the flavors of float. You would do the appropriate
floating-point contagion when the complex is created, not every time you
want to use it. I may be revealing my naivete here, but this just looks
like the right thing to do, pure and simple. It would clean up the
notation and make life easier for implementations that want to put in
special complex-number microcode or arrays for various complex types. I
know that this was discussed before, but I don't remember any resolution
of the problem -- it just sort of faded away. Is there really any
coherent argument for keeping things like #C(2/3 3.33e-1) around? If
nobody talks me out of this in the next few hours, I am tempted to put
this on a ballot.
-- Scott
∂05-Jun-83 1054 FAHLMAN@CMU-CS-C Results of ballot A
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 5 Jun 83 10:53:49 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 5 Jun 83 12:52:11 EDT
Date: Sun, 5 Jun 1983 12:52 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: common-lisp@su-ai
Cc: fahlman@CMU-CS-C
Subject: Results of ballot A
Results of Ballot A:
Evaluated by the same non-linear criteria as the last ballot, for the
same non-linear reasons.
There will be one last ballot, probably appearing later today. This
will contain some proposals on recursive reading, file names, and a few
odds and ends. That will probably be the last formal ballot before the
manual goes to press. There will be a period of proofreading, however.
---------------------------------------------------------------------------
A1. Add PARSE-INTEGER to replace the defunct PARSE-NUMBER: ACCEPTED. I
take it that BSG's clarification to this is acceptable: this function
does not parse the full Common Lisp integer syntax (including such
things as #R) but just slurps down digits in the radix provided by the
caller and returns an integer.
---------------------------------------------------------------------------
A2. PROCLAIM evaluates its arguments: ACCEPTED.
---------------------------------------------------------------------------
A3. Package name syntax: most people could accept either B or C, with a
marked preference for B among most of those indicating a preference. I
will take B as accepted and see what I can do to the "string-based"
interface functions that worry Moon. At the very least, we can make
these string-or-symbol and encourage users to use the symbol form so
that they won't get confused about case.
---------------------------------------------------------------------------
A4. Rearange args to VECTOR-PUSH and VECTOR-PUSH-EXTEND to match PUSH:
ACCEPTED.
---------------------------------------------------------------------------
A5. Add NTH-VALUE: REJECTED. The raw vote is almost exactly tied, but
the negatives are more vehement, the implementors are predominately
against, and the conservative principle that says in case of a tie we go
with the status quo.
---------------------------------------------------------------------------
A6. Add a set of primitives for named structures: REJECTED.
Implementors of DEFSTRUCT and similar packages will be encouraged to
confine any implementation-specific code for dealing with named
structures in a small, easily changed part of the package.
---------------------------------------------------------------------------
A7. Flush SET: REJECTED. Flush FSET: APPROVED.
---------------------------------------------------------------------------
A8. Make (APPLY '(LAMBDA ...)) be an error: REJECTED. The debate over
how far in the direction of Scheme we want to go will undoubtedly
continue, and we may go farther in the second edition, but a complete
restructuring of the traditional role of lambda and function names was
generally viewed as unwise at this time. Users should be encouraged to
use #'(LAMBDA ...) wherever appropriate. Guy should be encouraged to
clarify the definitions of "function", "compiled function", and how all
this relates to lexical closures in the manual. Certain things are
inconsistent at present.
---------------------------------------------------------------------------
A9. Reinstate VREF: REJECTED, narrowly.
---------------------------------------------------------------------------
A10. Add integer seed to MAKE-RANDOM-STATE: In my opinion, Guy has
single-handedly shot this down by showing that the desired functionality
can be obtained through the existing mechansims, and that the proposed
new mechanism cannot do this as well. Unless someone can show that this
is wrong, I'm going to treat this proposal as REJECTED.
---------------------------------------------------------------------------
A11. Add APPLYHOOK mechanism: APPROVED. (Sigh, now I have to go
implement this thing -- still, it's probably worth the hassle.)
---------------------------------------------------------------------------
A12. Add DLET: REJECTED. People favoring some form of this slightly
outnumbered those who opposed it, but there was no agreement among those
in favor on the exact form that this macro should take. So the
competing plans will have to fight it out as yellow pages packages for
now, and maybe by the second edition we'll have a clear winner.
---------------------------------------------------------------------------
A13. Moon's proposed change to INTERN and FIND-SYMBOL: APPROVED.
---------------------------------------------------------------------------
A14. Rename MULTIPLE-VALUE to MULTIPLE-VALUE-SETQ: APPROVED. Several
people have proposed that we rename these things to "MV-". This was
debated long ago, the "MULTIPLE-VALUE-" prefix won out over "MV-", and I
take the matter as closed. Moon suggests that if we call this form
"MULTIPLE-VALUE-SETQ" we must make it take pairs of arguments. I don't
find this compelling, but I'll put this question on the last ballot.
---------------------------------------------------------------------------
A15. Add constants indicating values of various limits (maximum array
rank, etc.) in each implementation: APPROVED. Leave the values of these
limits completely up to the implementation, with no minima: REJECTED.
People felt that some sort of floor is required so that users could be
sure that normal cases (a 3-D array with indices of 1024 on each
dimension, for example) will be portable.
I sense a willingness to let Guy choose a reasonable set of floor
values, in consultation with the various implementors. The guiding
principle should be that the limits are generous enough that reasonable
human-written code will not push the limits, but not so generous that
the ability to write a Common Lisp for a small machine is NEEDLESSLY
impaired. A starting point might be proposal of 7 array dimensions, 50
named arguments (with no limit on rest args), and 7 return values.
Implementations will be encouraged to make their own limits as generous
as possible, so that even unreasonable machine-written code can be
handled if this does not impact performance in a negative way.
---------------------------------------------------------------------------
A16. Flush MACRO, add Guy's SET-MACRO: basically APPROVED. Several
people suggested that SET-MACRO is a bad name, and proposed instead a
MACRO-FUNCTION accessor upon which SETF works. If nobody objects
strongly to this, I will take this modification as being approved.
---------------------------------------------------------------------------
A17. Gaussian integers are to be stored in canonical form: APPROVED.
Only a few people felt themselves to be qualified to vote on this,
but these people strongly favored the proposal.
∂05-Jun-83 1112 fateman%UCBKIM@Berkeley gaussian rationals
Received: from UCB-VAX by SU-AI with TCP/SMTP; 5 Jun 83 11:12:41 PDT
Date: 5 Jun 83 11:13:57 PDT (Sun)
From: fateman%UCBKIM@Berkeley (Richard Fateman)
Subject: gaussian rationals
Message-Id: <8306051813.14080@UCBKIM.ARPA>
Received: by UCBKIM.ARPA (3.340/3.5)
id AA14080; 5 Jun 83 11:13:57 PDT (Sun)
Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.341/3.31)
id AA11635; 5 Jun 83 11:12:52 PDT (Sun)
To: common-lisp@su-ai
Frankly, complex arithmetic should not be designed by a consensus of Lisp
hackers. The difference between mathematical theory and computation
is perhaps not clear to Alan, but there is a difference between thinking
mathematically and computationally. For example, division by 0 is not
defined in a mathematical field. Computationally, division by 0 must
be treated SOME way. Similarly, -1 and -1+0*i can be said to be mathematically
identical, but that says very little about how to compute with them.
In particular, whether sqrt(*) gives an error or not. One view of
sqrt(-4) is that it should return -2. The sign of the answer clearly indicates
something funny went on.
I would propose that rather than vote on complex arithmetic in this forum,
real arithmetic only be specified, and allow someone at some later
time specify a package for complex.
∂05-Jun-83 1111 @MIT-MC:MOON@SCRC-TENEX Proposed elimination of mixed-type complex numbers
Received: from MIT-MC by SU-AI with TCP/SMTP; 5 Jun 83 11:11:16 PDT
Date: Sunday, 5 June 1983 13:50-EDT
From: MOON at SCRC-TENEX
To: Common-Lisp at SU-AI
Subject: Proposed elimination of mixed-type complex numbers
In-reply-to: The message of Sun 5 Jun 1983 11:11 EDT from Scott E. Fahlman <Fahlman@CMU-CS-C>
This would also eliminate the one-of-a-kind anomaly in type
expressions that (COMPLEX FLOAT) is not the same as (COMPLEX FLOAT *),
but rather is the same as (COMPLEX FLOAT FLOAT). The COMPLEX type
expression would be allowed only a single "argument."
∂05-Jun-83 1226 EAK@MIT-MC Results of ballot A
Received: from MIT-MC by SU-AI with TCP/SMTP; 5 Jun 83 12:25:57 PDT
Date: 5 June 1983 15:26 EDT
From: Earl A. Killian <EAK @ MIT-MC>
Subject: Results of ballot A
To: Fahlman @ CMU-CS-C
cc: common-lisp @ SU-AI
In-reply-to: Msg of Sun 5 Jun 1983 12:52 EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Gee, a 1024 x 1024 x 1024 array takes 2↑30 words (4 Gigabytes).
Does each implementation really have to support that?
∂05-Jun-83 1241 FAHLMAN@CMU-CS-C Results of ballot A
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 5 Jun 83 12:40:48 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 5 Jun 83 15:41:01 EDT
Date: Sun, 5 Jun 1983 15:41 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Earl A. Killian <EAK@MIT-MC>
Cc: common-lisp@SU-AI
Subject: Results of ballot A
In-reply-to: Msg of 5 Jun 1983 15:26 EDT from Earl A. Killian <EAK at MIT-MC>
Oops. No, requiring each implementation to support 4 Gigabytes of total
array size is probably a bit extreme. It would rule out any
implementation on most small computers such as the Vax and the 3600.
-- Scott
∂05-Jun-83 1557 ALAN@MIT-MC gaussian rationals, transcendental functions, etc.
Received: from MIT-MC by SU-AI with TCP/SMTP; 5 Jun 83 15:57:40 PDT
Date: 5 June 1983 18:58 EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: gaussian rationals, transcendental functions, etc.
To: Common-Lisp @ SU-AI
Date: 5 Jun 83 11:13:57 PDT (Sun)
From: fateman%UCBKIM at Berkeley (Richard Fateman)
Frankly, complex arithmetic should not be designed by a consensus of Lisp
hackers. The difference between mathematical theory and computation
is perhaps not clear to Alan, but there is a difference between thinking
mathematically and computationally.
I believe I have now argued this point from both mathematical and
computational standpoints, and have demonstrated how to fit the two
together acceptably. I'll not continue to argue the issue. If a degree in
mathematics and several years experience as a "Lisp hacker" don't qualify
me to have an intelligent opinion on this subject in fateman's eyes, so be
it. If anyone else would like to say something new on the subject...
The issue raised by Fahlman about needing a rule that says that that
putting in a real gets you a real answer if possible, is dealt with by
specifying appropriate ranges for the transcendental functions. In the
laser manual, GLS has already suggested ranges that have this property.
(This is nothing new really, mathematicians have always chosen the
principle values of such functions to satisfy Fahlman's rule.) Let me
reiterate what I said yesterday: the only new behavior exhibited by that
handful of transcendental functions, when given a pure real argument, would
be the generation of a complex number in some cases, rather than an error.
BTW, I accidentally excluded the EXPT function from my list of
transcendental functions that have "questionable" (from a user-interface,
or "computational" viewpoint) regions in the real part of their domains.
So make that 7 functions with the "problem".
The suggestion that numbers like #C(3/4 3.14159) be eliminated has a
certain appeal. Would the proposal extend to eliminating numbers like
#C(1.0S0 1.0L0)? Eliminating such mixed floating types might frowned upon
by the masters of floating point, although I can also imagine that
converting this to #C(1.0L0 1.0L0), (that is, converting to the maximum of
the two precisions), would be acceptable to them.
∂05-Jun-83 1700 FAHLMAN@CMU-CS-C gaussian rationals, transcendental functions, etc.
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 5 Jun 83 17:00:28 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 5 Jun 83 20:00:33 EDT
Date: Sun, 5 Jun 1983 20:00 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Alan Bawden <ALAN@MIT-MC>
Cc: Common-Lisp@SU-AI
Subject: gaussian rationals, transcendental functions, etc.
In-reply-to: Msg of 5 Jun 1983 18:58 EDT from Alan Bawden <ALAN at MIT-MC>
If Fateman has a specific gripe or a specific proposal to make, he
should make it. If his only proposal is that we should eliminate
complex numbers from the language until we can find a REAL mathematician
who understands this stuff, all I can say if that it is too late to
consider such a sweeping change, and will just have to muddle through
with the motley assortment of talent available on this list. If we make
some sort of mistake this time around, we can always correct it later.
The suggestion that numbers like #C(3/4 3.14159) be eliminated has a
certain appeal. Would the proposal extend to eliminating numbers like
#C(1.0S0 1.0L0)?
Yes. There would be exactly as many types of complex number as there
are types of floating point, plus the type in which both halves are
rational. The COMPLEX function and other functions that create complex
numbers would take any mixture of arguments and would do the usual
foating-point contagion at creation time.
-- Scott
∂05-Jun-83 1755 GJC@MIT-ML Complex Arguments, fear and loathing on the number line.
Received: from MIT-ML by SU-AI with TCP/SMTP; 5 Jun 83 17:55:27 PDT
Date: 5 June 1983 20:57 EDT
From: George J. Carrette <GJC @ MIT-ML>
Subject: Complex Arguments, fear and loathing on the number line.
To: ALAN @ MIT-ML
cc: COMMON-LISP @ SU-AI
My feeling is that adding simplification rules on the results of
a function are ok as long as it doesn't get out of hand. One might
write this:
(defmethod ((complex complex) :plus) (x y)
(make-complex (+ (send x :real) (send y :real))
(+ (send x :imag) (send x :imag))))
And if make-complex is a routine which checks for the simplification
case I don't mind, although I would mind if this sets a precedent
for more simplification rules. It could simply get very complex
and slow down the implementations enough so that potential users
would go back to their own devices such as MAKE-COMPLEX = CONS.
That is why I would shy away from making any claims about disallowing
certain forms of numbers. I find nothing wrong with #C(3.3 5)
or #C(0.3 3/4), although it might not be easy to generate such
a thing besides having typed it in. (e.g.
(+ 3.3 #C(0 3/4)) is sure to produce #C(3.3 0.75) naturally, by
3.3 => #C(3.0 0.0) ; extend to complex by getting the ZERO of the type of 3.3)
The same argument goes for various forms of non-uniform floating-point
combinations. Even if somebody does type one in I don't see how a
good implementation of the arithmetic would care.
Maybe this is another good time to quote from the "Federalist Papers"
about how it isn't a good idea to make a law against something that
you can't fathom happening anyway.
∂05-Jun-83 1945 Walter.VanRoggen@CMU-CS-A minimum multiple values
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 5 Jun 83 19:45:23 PDT
Date: 5 June 1983 2241-EDT (Sunday)
From: Walter van Roggen <Walter.VanRoggen@CMU-CS-A> (C410WV50)
To: Fahlman@cmu-cs-c
Subject: minimum multiple values
CC: common-lisp@su-ai
Message-Id: <05Jun83.224137.WV50@CMU-CS-A>
For you multiple-value aficionados, remember that GET-DECODED-TIME
returns 9 multiple values. BTW, I think using "MV-" as a prefix would
encourage their use.
---Walter
∂06-Jun-83 0111 FAHLMAN@CMU-CS-C Revenge of the Ballot
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 6 Jun 83 01:10:34 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 6 Jun 83 03:01:56 EDT
Date: Mon, 6 Jun 1983 03:01 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: common-lisp@su-ai
Cc: fahlman@CMU-CS-C
Subject: Revenge of the Ballot
Ballot B:
A few loose ends. With luck, this will be the final ballot before the
manual is finalized for the first edition. There may be a couple of
messages on single issues that pop up during final cleanup of the
manual, but this should be the last multi-issue submission.
Please reply by dawn, Tuesday morning. I plan to collate the answers
later in the day on Tuesday.
---------------------------------------------------------------------------
B1. Proposed that we require both halves of a complex number to be of
the same type, either both rationals or both floats of the same type.
The COMPLEX function will accept numeric arguments of mixed type, but it
will do floating-point contagion of the usual sort (floats dominate
rationals, floats of greater precision dominate those of lesser) before
returning the complex number.
[ I am not really qualified to have an opinion on this. It would make
the system easier to implement, easier to understand, and it would get
rid of an ugly exception or two. On some hardware (the S-1, for
example) homogeneous-type complexes can be handled by the hardware,
while mixed types are more awkward. Therefore, if none of the
mathematicians in the audience has a good reason NOT to do this, it
looks like a good move to me. ]
---------------------------------------------------------------------------
B2. Proposed that we adopt Alan Bawden's suggestion that we return a
complex number from functions like (sqrt -1), where we would otherwise
have to signal an error. If not this, please indicate what you think we
should do.
[ Same comment as above. If we're going to have complexes (and we are),
it seems wrong for (sqrt -1) not to return one. ]
---------------------------------------------------------------------------
B3. Now that we have decided to change from MULTIPLE-VALUE to
MULTIPLE-VALUE-SETQ, Moon says that we must have this form take
pairs of arguments like SETQ and PSETQ. Yes or no?
[ I say no. The format is completely different since there is a list of
N variables and one value-producing form. I don't think anyone will
assume that it must take pairs of variables (variable-lists, really) and
values as SETQ does. To add this would be MORE confusing, not less. ]
---------------------------------------------------------------------------
B4. Proposals by Robert Cassels to change FLOAT-SIGNIFICAND and friends.
[ These all look like good changes to me. There were also a couple fo
suggested clarifications to the manual that Guy can deal with. Vote on
each part separately if you need to. ]
B4a. Proposal: Remove FLOAT-EXPONENT and FLOAT-INTEGER-EXPONENT, and
return those numbers as the second values from FLOAT-SIGNIFICAND and
FLOAT-INTEGER-SIGNIFICAND.
This would serve to make these functions more similar to the division
functions, and emphasize the close relationship between the values. It
also leads to slightly improved efficiency of implementation,
particularly on systems with unnormalized (or denormalized) numbers, and
those with "non-numeric" floating-point values [IEEE floating-point,
anyone?] which must be checked. (I'm assuming that when one value is
wanted, the other is almost always wanted also.)
B4b: Proposal: Add new functions FLOAT-DIGITS and FLOAT-PRECISION.
(FLOAT-DIGITS float) would return the number of (FLOAT-RADIX
float) digits used in the representation of a floating-point number.
(Including the "hidden bit", if any.) For most implementations, this is
really a property of the type of float.
(FLOAT-PRECISION float) would return the number of significant
(float-radix float) digits present in float.
Implementation: For implementations using only normalized numbers, these
functions would be identical. (- (FLOAT-DIGITS float) (FLOAT-PRECISION
float)) would reflect the degree of denormalization of float.
These functions are needed to simplify the movement of floating-point
numbers from one implementation to another. They are also needed to
convert numbers from one base to another in a way which reflects the
precision (doesn't print bogus digits). FLOAT-DIGITS could be
computed for most implementations by (- (FLOAT-EXPONENT 1.0)
(FLOAT-EXPONENT SINGLE-FLOAT-EPSILON)) or something like that. But
making it a function seems cleaner than some sort of typecase.
B4c. Proposal: Require the result of FLOAT-INTEGER-SIGNIFICAND to
reflect the precision of the floating-point number.
Currently, FLOAT-INTEGER-SIGNIFICAND is only required to satisfy the
identity relating it to FLOAT-INTEGER-EXPONENT. That allows the result
to be scaled by various powers of the radix, so long as the exponent is
adjusted appropriately. So if @i[b] is (FLOAT-RADIX float) and @i[p] is
(FLOAT-PRECISION float), the result of (FLOAT-INTEGER-SIGNIFICAND float)
for non-zero float should be between (EXPT b p) (exclusive) and (EXPT b
(1- p)) (inclusive).
---------------------------------------------------------------------------
B5. We've stil got to settle the business of top-level vs. recursive
calls to READ and friends. Having considered all of the mail that has
flown by on this, I re-propose the following:
All of the functions that now take EOF-ERRORP and EOF-VALUE arguments
(except for READ-BYTE and READ-BINARY-OBJECT) will take an additional
optional arg after EOF-VALUE. This arg, RECURSIVE-P, should be NIL if
the function is called at the top level in a read, T otherwise. It
defaults to NIL. If this is non-null, the eof actions are controlled
not by the funciton's own controls, but by the top-level call. Also,
only top-level calls rebind the ## environment, etc.
I was thrown for a bit of a loop by Eric Benson's suggestion that
read-macro functions have to know whether they are at top-level so that
they will know whether their own calls to read are recursive or
top-level. That seemed to require some heavy-duty changes until I
realized that a macro-character function is always called within a READ,
so it always wants to the calls it makes to be recursive, unless perhaps
it is initiating some sort of top-level dialogue with the user instead
of gobbling down more of the stream in which the macro character was
read. Of course, this assumes that you don't call random
character-macro functions directly, but that they only get called by the
reader.
[ I think this does it. Propose alternatives if you want to, but also
please indicate whether you can live with this. ]
---------------------------------------------------------------------------
B6. Rename MERGE-PATHNAME-DEFAULTS to MERGE-PATHNAMES and eliminate the
default-type argument. (This is obtained from the defaults.)
[ Suggested by the folks at Symbolics who have experience with these
things. They claim that users get terribly confused if the default type
present in the DEFAULTS argument is not used. Sounds good to me.]
---------------------------------------------------------------------------
B7. Propose that we add a new slot, CONVENTION, to the pathname
structure, and an optional CONVENTION argument to the PATHNAME and
TRUENAME functions. This convention is used in parsing the argument, if
it is a string, and is recorded in the resulting pathname structure so
that the pathname can be turned back into a namestring in the same
format. CONVENTION is a symbol, not a string; the collection of
meaningful convention symbols is implementation-dependent.
PARSE-NAMESTRING, which already has a convention argument, would be
brought into conformity with this.
The rule should be that the convention, if it is supplied, is used to
guide the parsing, and an error is signalled if the string is not legal
in this convention. If the convention is not supplied, the system will
examine the string and attempt to deduce the convention in some grossly
implementation-specific or site-specific way, perhaps by recognizing the
host name and looking up that host's convention in a table. We should
not specify anything about how this is done; in particular, do not
specify that the host is delimited by "::".
The point is that the current proposal (a simplified subset of the
existing Lispm pathname facility) muddles together the notion of HOST
(the machine or network node where the file resides) and CONVENTION
(what file-naming convention is used in this file name). A host might
be "CMUC"; its convention might be "TOPS-20". A convention runs on many
hosts, and it is quite possible that some hosts will provide more than
one convention. (Our 3600's may one day have a band full of
Symbolics-format files and a band full of Spice-format files, coexisting
happily; there are other examples around.) In any event, code can be
more portable if it can deal with something as a Tops-20 filename than
as "whatever CMUC is". Many places in the pathname section refer to
some feature as "host-dependent", when in fact it depends on the
convention.
[ I'm in favor. ]
∂06-Jun-83 0136 ALAN@MIT-MC Revenge of the Ballot
Received: from MIT-MC by SU-AI with TCP/SMTP; 6 Jun 83 01:36:08 PDT
Date: 6 June 1983 04:38 EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: Revenge of the Ballot
To: Fahlman @ CMU-CS-C
cc: Common-Lisp @ SU-AI
In-reply-to: Msg of Mon 6 Jun 1983 03:01 EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
I vote Yes for 1 and 2.
I abstain from voting on all of the rest.
∂06-Jun-83 0718 @USC-ECL,@MIT-MC:BSG%SCRC-TENEX@MIT-MC PARSE-INTEGER
Received: from USC-ECL by SU-AI with TCP/SMTP; 6 Jun 83 07:18:36 PDT
Received: from MIT-MC by USC-ECL; Mon 6 Jun 83 07:16:28-PDT
Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Mon 6-Jun-83 10:09:57-EDT
Date: Monday, 6 June 1983, 10:09-EDT
From: Bernard S. Greenberg <BSG%SCRC-TENEX@MIT-MC>
Subject: PARSE-INTEGER
To: common-lisp%su-ai@usc-ecl
As currently specified, PARSE-INTEGER will not accept signed integers.
That's correct. It should, however, have a :sign-allowed keyword,
default NIL, to allow this, right?
∂06-Jun-83 0748 FAHLMAN@CMU-CS-C PARSE-INTEGER
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 6 Jun 83 07:47:44 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 6 Jun 83 10:47:20 EDT
Date: Mon, 6 Jun 1983 10:47 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Bernard S. Greenberg <BSG%SCRC-TENEX@MIT-MC>
Cc: common-lisp@su-ai
Subject: PARSE-INTEGER
In-reply-to: Msg of 6 Jun 1983 10:09-EDT from Bernard S. Greenberg <BSG%SCRC-TENEX at MIT-MC>
Bernie,
Adding :SIGN-ALLOWED to PARSE-INTEGER seems like an uncontroversial
suggestion, as long as it's not the first of N such messages. Unless
someone pops up and objects, I will consider this to be approved.
-- Scott
∂06-Jun-83 0758 FAHLMAN@CMU-CS-C Ballot clarification
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 6 Jun 83 07:58:14 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 6 Jun 83 10:55:06 EDT
Date: Mon, 6 Jun 1983 10:55 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: common-lisp@su-ai
Subject: Ballot clarification
KMP has asked for a clarification on issue 5B. It seems clear enough to
me, but what I'm asking for is a YES/NO vote on whether the proposed
mechanism looks reasonable enough to you that you could live with it.
Whichever way you vote on this, you are welcome to offer alternative
suggestions that you like better: "Bring back SUB-READ", etc.
The reason that I've phrased it this way is that I'm afraid that this
issue will end up like DLET: 53 different plans and no consensus.
That's fine for DLET, since we can defer the issue, but it would be
awkward not to have a reader until the second edition, so if all the
suggestions diverge, I am trying to get a feeling for whether my
proposal is at least acceptable, if not optimal, in the eyes of this
community.
-- Scott
∂06-Jun-83 0953 RPG One last diddle to my error proposal
∂24-May-83 1309 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN One last diddle to my error proposal
Received: from MIT-MC by SU-AI with TCP/SMTP; 24 May 83 13:08:50 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Tue 24-May-83 15:24:16-EDT
Date: Tuesday, 24 May 1983, 15:21-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: One last diddle to my error proposal
To: Scott E. Fahlman <Fahlman%CMU-CS-C@SU-DSN>
Cc: David A. Moon <Moon%SCRC-TENEX%mit-mc@SU-DSN>, common-lisp@su-ai
In-reply-to: The message of 24 May 83 12:09-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: Tue, 24 May 1983 12:09 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
I don't feel passionately about this switch,
[switch of the order of the first two arguments to CERROR]
but to me it seems much more
intuitive to have the "error message" string come before the "and if you
proceed" string. They will presumably appear in the original order in
the error dialogue. I bet if we switch it, lots of users will get burned
the first few times they use it.
This could be a problem, and indeed that's the reasoning I followed
originally that caused me to put the continue-message string first. On
the other hand, since it's called "C ERROR" the "C" part should come
before the "ERROR" part. We can't win.
You don't say why you want to make the switch -- just so it looks more
like ERROR if you cover up the function name and the first arg?
Exactly. Now, the reason why that is important will not appear until Common
Lisp has conditions. I'm not going to send out a proposal for conditions
until after the first edition of the manual is out, to avoid distraction
from more important things. But I'm thinking about it a little.
∂06-Jun-83 0953 RPG One last diddle to my error proposal
∂24-May-83 1315 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN One last diddle to my error proposal
Received: from MIT-MC by SU-AI with TCP/SMTP; 24 May 83 13:15:18 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Tue 24-May-83 15:24:16-EDT
Date: Tuesday, 24 May 1983, 15:21-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: One last diddle to my error proposal
To: Scott E. Fahlman <Fahlman%CMU-CS-C@SU-DSN>
Cc: David A. Moon <Moon%SCRC-TENEX%mit-mc@SU-DSN>, common-lisp@su-ai
In-reply-to: The message of 24 May 83 12:09-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: Tue, 24 May 1983 12:09 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
I don't feel passionately about this switch,
[switch of the order of the first two arguments to CERROR]
but to me it seems much more
intuitive to have the "error message" string come before the "and if you
proceed" string. They will presumably appear in the original order in
the error dialogue. I bet if we switch it, lots of users will get burned
the first few times they use it.
This could be a problem, and indeed that's the reasoning I followed
originally that caused me to put the continue-message string first. On
the other hand, since it's called "C ERROR" the "C" part should come
before the "ERROR" part. We can't win.
You don't say why you want to make the switch -- just so it looks more
like ERROR if you cover up the function name and the first arg?
Exactly. Now, the reason why that is important will not appear until Common
Lisp has conditions. I'm not going to send out a proposal for conditions
until after the first edition of the manual is out, to avoid distraction
from more important things. But I'm thinking about it a little.
∂06-Jun-83 0954 RPG Finishing the Manual: Final Offer
∂25-May-83 0913 FAHLMAN@CMU-CS-C Finishing the Manual: Final Offer
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 25 May 83 09:13:19 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 25 May 83 12:13:16 EDT
Date: Wed, 25 May 1983 12:13 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: steele@CMU-CS-C
Cc: moon%scrc-tenex@mit-mc, dlw%scrc-tenex@mit-mc, declisp@CMU-CS-C,
vanroggen@CMU-CS-C, rpg@su-ai, fahlman@CMU-CS-C, newell@CMU-CS-A,
mcdermott@CMU-CS-A, raj.reddy@CMU-CS-A
Subject: Finishing the Manual: Final Offer
Guy,
As you know, I've been trying to reach you for a week and trying
intensively to reach you for the last three days. According to your
secretary at Tartan, you have not "been at your desk", you have not
returned my calls, and you have not answered any computer mail in
months. I am not willing to start calling you at home, bill-collector
style. If you don't want to communicate with me or with anyone else
about Common Lisp, I'm not going to try to force you.
It is now over a month since you said that you'd pull out all the stops
to finish the manual by the end of April, or as soon thereafter as
possible. It is over two weeks since Bill Wulf agreed to let you work
on the manual on company time. We are still in effectively the same
state we were in before this last "big push": total paralysis, induced by
the lack of a definitive manual and the lack of any effective way of
telling what is happening with the manual and which proposals are likely
to be accepted.
It is clear that you have done some editing, resulting in the May 10
shipment of files, but these address only about half of the issues
people have raised (see Moon's analysis in file
PRVA:<SLISP.SCL>LASER.UPDATE on CMUC). Despite my request to you at
Black Friday (May 13), we have not received any indication of which
parts of the manual are to be considered definitive, which of the
unanswered suggestions are oversights, which are still pending, and
which you have considered and rejected.
I don't believe that you realize how terribly disruptive and
demoralizing this state of affairs is to those of us trying to implement
this unspecified language. The continued delays and lack of
communication and status information are threatening the unity of the
Common Lisp effort, and they are doing terrible things to the schedules
of the DEC project, Spice Lisp, and the effort at Symbolics. The worst
effect is on morale -- I don't know about the rest of the participants,
but I am now very sorry indeed that I ever got involved in a joint
effort of this sort.
For my part, I have made a decision. The implementation efforts that I
am involved in are no longer interested in being a part of Common Lisp
as long as the final definition of Common Lisp is under your control, in
the sense that all decisions must wait for some action on your part
before they become final and documented. As of this moment, I am no
longer interested in hearing about your plans to finish the manual in
just a few more weeks or days or hours. I believe that I speak for the
DEC Vax effort in this, and I believe that the people at Symbolics feel
roughly the same way. It is now clear to all of us that it would be ten
times easier and a thousand times less stressful for someone else to
finish the manual than for us to try to get you to finish the manual.
And the manual must be finished, or dozens of man-years of effort and a
real opportunity to do something good goes down the drain.
I propose the following as a way to salvage something from this
unfortunate mess:
1. You turn the files now on CMUC, or any more recent versions that you
have hidden at Tartan, over to me. Working with Moon, Weinreb, and
Gabriel (if he wants to become actively involved in this), I will
attempt to resolve any outstanding issues via very quick arpanet
exchanges and then make the final edits.
2. I am willing to drop nearly everything else and to work day and night
on this until it is done.
3. My sole interest in this is to get the manual done, and to make sure
that the process of preparing subsequent editions does not stall as this
one has. Since the exisitng 90% of the manual is your work, I am
willing to leave you listed as sole author and to let you collect all
the royalties from publication, if that's the way you want it. (I
cannot speak for the others on this, however.) We will have to work out
some agreement on the copyright to ensure that a second edition will
appear a year from now, even if you do not participate.
4. I am not asking you to give up control completely. All changes would
be debated on the net, and I would treat any major objections from you
as being vetos. My high opinion of your taste as a language designer is
undiminished. However, if you do not respond on some issue, the rest of
us will feel free to resolve it without your input. We're going to be
moving very fast on this.
I would be willing to listen to other proposals that will accomplish the
same effect. Perhaps everyone would be more comfortable if Moon,
Weinreb, or Gabriel took over the effort instead of me.
Of course, since we decided to sign the copyright on the manual over to
you, you have the legal power to block this proposal, and to prevent
anyone else from building on the existing manual text. If you still
care at all about Common Lisp, you will not exercise this power.
I'm very sorry it has come to this. I wish that you had accepted one of
my earlier offers to help on this, or that you had somehow found the
time to do the job yourself, but we cannot change the past. I hope that
we can still salvage something.
-- Scott
∂06-Jun-83 0954 RPG
∂25-May-83 1158 RPG Common Lisp Offer
To: RPG@SU-AI
Scott:
I am willing to put in a lot of effort to help finish the manual. I have
just now officially requested from the S-1 project a month of full-time
manual hacking, to start the end of next week. I am sure they will see
no problem with this.
In particular, I will help with all technical decisions, though I am
happy enough (as my silence is intended to imply) with the decisions
that have been made recently. I will help with the writing, and especially
the polishing, of any or all of the manual. If you would like to first-draft
sections of it, I will complete them for you.
I would be willing to travel to CMU in June for a week to help you in person,
if necessary.
I am puzzled by Steele's behavior (as you describe it) since, when I
talked to him a few weeks ago, everything seemed to be going fine. I hope
that nothing has happened to him or his immediate circle.
-rpg-
∂06-Jun-83 0954 RPG Offer
∂25-May-83 1228 FAHLMAN@CMU-CS-C Offer
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 25 May 83 12:28:03 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 25 May 83 15:29:03 EDT
Date: Wed, 25 May 1983 15:29 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Dick Gabriel <RPG@SU-AI>
Cc: Fahlman@CMU-CS-C
Subject: Offer
In-reply-to: Msg of 25 May 83 1202 PDT from Dick Gabriel <RPG at SU-AI>
Dick,
Your offer to help is greatly appreciated. Needless to say, taking over
the manual will rip about a month out of my summer that was already
pretty full, and sharing the load will help a lot. I think that there's
only about two weeks of actual work to do, including figuring out Guy's
funny Scribe macros and hassling with our Dover. Add to that a couple
more weeks to resolve all the last minute stuff.
I know that my message was strongly worded. What you heard was the
sound of the proverbial camel's back breaking.
I have been getting more and more ticked off about Guy's lack of
responsiveness for months, since even before the last-minute effort that
produced the Laser edition, with all its problems. I think that Guy is
OK, but that he has grossly overcommitted himself, feels guilty about
this, and is avoiding contact with me for the same reason I used to
avoid running into my thesis advisor. He's embarrassed. But his
response takes the form of freezing up and not of digging in and getting
this off his stack. I know that he believes he is on various critical
path things at Tartan (though Wulf was perfectly happy to have him work
on Common Lisp instead), and I know that Barb has been pressuring him to
work 9 to 5 and no more than that. So he's got all these conflicting
pressures and probably loathes the very mention of Common Lisp at this
point. Or that's my guess. I have offered several times to take the
whole mess off his hands. More than that I cannot do.
I imagine that Guy will think I'm over-reacting and that the obvious
thing to do is just to leave him alone to finish this at his own pace.
You understand why that is no longer an option, after 5 or 6 months of
broken promises and missed estimates, and with real comapnies paying
real money for these implementations.
When Wulf told him it was OK to hack Common Lisp on Tartan time, he
seemed to perk up for a day or two, and he got those new files over.
But since then it's back to the same old thing. I just haven't seen
him, and when I call, the secretary says he's in, then asks who is
calling, then discovers he's gone. She's not a very good liar.
I thought about starting to call him at home or to tell the secretary
that it was Ronald Reagan calling, but enough is enough. Hence my note.
You know him better than I do. Maybe you can find out what's happening
in his head. Id' be interested in any independent views of this.
-- Scott
∂06-Jun-83 0955 RPG Offer
∂25-May-83 1434 FAHLMAN@CMU-CS-C Offer
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 25 May 83 14:32:18 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 25 May 83 17:32:58 EDT
Date: Wed, 25 May 1983 17:32 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Dick Gabriel <RPG@SU-AI>
Subject: Offer
In-reply-to: Msg of 25 May 83 1202 PDT from Dick Gabriel <RPG at SU-AI>
Some additional data on Guy's state: a relaible source at Tartan tells me
that Guy has spent much of the last week putting the finishing touches
on the hacker's jargon file, which he is publishing somewhere. This
says something about his priorities, I think. He does seem to be in
reasonably good spirits overall and working on assorted things. When
asked by this person how the manual is coming, he says he doesn't want
to talk about it. The manual files appear not to have been touched
since May 10.
I would appreciate it if you didn't confront Guy with this info -- I'd
rather not have my source's cover blown. But it does make me feel like
I've done the right thing.
-- Scott
∂06-Jun-83 0948 @MIT-MC:DLW%SCRC-TENEX%MIT-MC@SU-DSN Re: Results of ballot A
Received: from MIT-MC by SU-AI with TCP/SMTP; 6 Jun 83 09:48:36 PDT
Date: 6 Jun 1983 1158-EDT
From: Daniel L. Weinreb <DLW%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Re: Results of ballot A
To: Fahlman%CMU-CS-C@SU-DSN
cc: EAK%MIT-MC@SU-DSN, common-lisp@SU-AI
In-Reply-To: The message of Sun, 5 Jun 1983 15:41 EDT from Scott E. Fahlman <Fahlman@CMU-CS-C>
Well, likewise, if I write a program that loops four billion times calling
CONS each time, that doesn't violate the Common Lisp standard in any way
at all, yet it might reasonably be expected to fail in some implementations.
So no implementation can possibly be valid.
The intent of the requirement about minima for the maximum array size
is presumably to make sure that the implementation can REPRESENT such
arrays, even though attempting to CONS one at any time might run you out
of free storage. I'm not sure how to phrase this in a completely clear
way for the manual, but I don't think that getting rid of the 1024 thing
is necessarily valid.
-------
∂06-Jun-83 0956 RPG Common Lisp Calls!
∂26-May-83 1029 JMB@S1-A Common Lisp Calls!
Received: from S1-A by SU-AI with TCP/SMTP; 26 May 83 10:29:10 PDT
Date: 26 May 83 1024 PDT
From: Jeff Broughton <JMB@S1-A>
Subject: Common Lisp Calls!
To: rpg@SU-AI
∂25-May-83 1128 RPG@SU-AI Common Lisp Calls!
Received: from SU-AI by S1-A with TCP/SMTP; 25 May 83 11:28:38 PDT
Date: 25 May 83 1130 PDT
From: Dick Gabriel <RPG@SU-AI>
Subject: Common Lisp Calls!
To: jmb@S1-A
I am sending under separate cover a note from Fahlman to several of us
principals in the Common Lisp Group, discussing Steele and the manual.
I would like to throw my energies into the manual-completing project.
I plan to work starting friday until saturday, week, with Rod on the compiler
and GC code. I'd like to spend up to a month on the manual with Fahlman and
Moon. My question is: will you (and Tom?) approve of this activity as
project related? I hope so, since Common Lisp may be sunk unless something is
done.
-rpg-
[Seems project related to me. -jmb]
∂06-Jun-83 0956 RPG Common Lisp Manual
∂26-May-83 1151 JMB@S1-A Common Lisp Manual
Received: from S1-A by SU-AI with TCP/SMTP; 26 May 83 11:51:09 PDT
Date: 26 May 83 1046 PDT
From: Jeff Broughton <JMB@S1-A>
Subject: Common Lisp Manual
To: rpg@SU-AI
I a more than a little bit concerned about the discussion of the copyright
on the Common Lisp manual, particularly the parts about control and royalities
for publication.
Since this work was partially supported with government funds, there can be no
personal, corporate or other copyrights associated with it. PERIOD. All
participants, particularly Steele, should be aware that if any attempt is
made to profit from its publication or to restrict its release, appropriate
injunctions or damages will be sought.
I could get still more excited about this, but I will let you reassure me
that things are not as bad as they seem.
-jmb
∂06-Jun-83 0957 RPG Comments on LASER.UPDATE
∂27-May-83 0623 FAHLMAN@CMU-CS-C Comments on LASER.UPDATE
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 27 May 83 06:22:33 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 27 May 83 09:23:12 EDT
Date: Fri, 27 May 1983 09:23 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: STEELE@CMU-CS-C
Cc: declisp@CMU-CS-C, dlw%scrc-tenex@MIT-MC, guy.steele@CMU-CS-A,
moon%scrc-tenex@MIT-MC, rpg@SU-AI, vanroggen@CMU-CS-C
Subject: Comments on LASER.UPDATE
In-reply-to: Msg of 27 May 83 01:23:14 EDT from STEELE
Guy,
Thanks for getting this pass done. I will use this this list (and some
other things in the mail file) to generate a series of mini-ballots and
proposals, and see if we can wrap up these decisions as quickly as
possible.
If any of the rest of you on this list, acting as a sort of "executive
committee", want to flag certain additional things as controversial or
come in early with opinions on some of them, feel free. When I do send
these out to Common Lisp, I will be making a strong recommendation on
each, and on some of them I will be checking with some or all of you to
get advice on what that recommendation should be.
-- Scott
∂06-Jun-83 0957 RPG
∂27-May-83 1052 JMB@S1-A
Received: from S1-A by SU-AI with TCP/SMTP; 27 May 83 10:52:01 PDT
Date: 27 May 83 0946 PDT
From: Jeff Broughton <JMB@S1-A>
To: rpg@SU-AI
Jeff,
Here are the lastest notes on the Common Lisp manual.
It seems I won't have to spend all my time on it, but, by phone,
I've agreed to go a lot of work over the next 3 weeks or so on it.
These messages contain info on the copyrights. I know that Steele
will ne paid royalties on the book (aka the manual) when published by
DEC.
Your last sentence does not reassure me. This will get Guy into a
lot of trouble. I think that you should talk with him.
-jmb
∂06-Jun-83 0958 RPG [Moon%SCRC-TENEX: New setf writeup]
∂27-May-83 2218 FAHLMAN@CMU-CS-C [Moon%SCRC-TENEX: New setf writeup]
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 27 May 83 22:15:45 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 28 May 83 01:16:50 EDT
Date: Sat, 28 May 1983 01:16 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: rpg@su-ai
Subject: [Moon%SCRC-TENEX: New setf writeup]
Just sent this to Guy, meant to CC you too...
Guy,
I asked Moon to write up his hairy DEFSETF proposal in manual-insertion
format. He has done so and the result is on <fahlman.clm>defsetf.mss.
This writeup looks good to me -- it's hairy, but doing DEFSETF right has
to be hairy. The substance of this proposal has kicked around the
Common Lisp circuit several times, so it take it to be "approved"
already -- I even sent out a last call for quibbles awhile back.
The one new item is the elimination (for now at least) of the provision
for the new-value argument to take a lambdalist to handle multiples.
This too went around the list. That second lambda-list was your baby,
so if you don't object to its elimination, then I'm sure that nobody
else does. We are retaining the (x) syntax so that we can make this a
full lambda list later, if we ever find some good reason to.
This file may not be in totally legal Steelese Scribe. Probably the
quickest thing is for you to make a pass over it and then stick it in if
you don't spot anything bogus. If you want someone to proof it through
Scribe before it goes in, I'll ask Monica to, but that will add a couple
of days since her stack is already full.
I had hoped that by tonight I could get back to you on all the "OK by
me" issues you flagged, either to tell you that all of these are also OK
by me or perhaps to take exception to one or two of them. This will
have to wait till sometime tomorrow, probably in the evening. I lost
almost a whole evening tonight -- went to the airport to pick up Penny's
brother and his wife and U.S.Error kept us hanging around for 3 1/2
extra hours! I didn't think to take any work along.
I'm not sure what sort of confirmation you want on these "OK by me"
issues. Obviously thse are OK by Moon & Co. and by you. I'll sign off on
almost all of them tomorrow, and maybe you should ask RPG to do so as
well. I think that with that much confirmation, it's OK to put these in
the manual. In going through them, I'll try to flag any that are so
controversial they might need a vote, even if I agree with them.
Once we're clear on those items, I'll start sending out messages on the
controversial ones -- those on Moon's list and those raised in some
of the other recent messages.
There's one item that really has to be dealt with by you: Benson's very
recent message on separating the names of functions from the functions
themselves, with lambda expressions being the former. This looks
somewhat dubious to me, and has drawn an objection from Bawden. This is
clearly an issue on which you are the best qualified to speak, one way
or the other, since Benson's suggestion was inspired by the "Art of the
interpreter" paper. This doesn't have to be handled before you finish
the current editing pass, but the issue probably won't go away till you
comment on it.
-- Scott
∂06-Jun-83 0956 RPG Follow up
Jeff,
Here are the lastest notes on the Common Lisp manual.
It seems I won't have to spend all my time on it, but, by phone,
I've agreed to go a lot of work over the next 3 weeks or so on it.
These messages contain info on the copyrights. I know that Steele
will ne paid royalties on the book (aka the manual) when published by
DEC.
-rpg-
∂25-May-83 2118 FAHLMAN@CMU-CS-C Follow up
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 25 May 83 21:18:42 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 26 May 83 00:18:27 EDT
Date: Thu, 26 May 1983 00:18 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: moon%scrc-tenex@mit-mc, dlw%scrc-tenex@mit-mc, declisp@CMU-CS-C,
vanroggen@CMU-CS-C, rpg@su-ai, fahlman@CMU-CS-C, newell@CMU-CS-A,
mcdermott@CMU-CS-A, raj.reddy@CMU-CS-A, peter.hibbard@CMU-CS-A
Cc: Steele@CMU-CS-C
Subject: Follow up
I just got a call from Guy and we discussed how to proceed in light of
my message earlier today.
Guy made clear that he is still committed to the goals of the Common
Lisp effort. He also made clear that he would not use his copyright to
prevent the rest of us from finishing the manual, if that should become
necessary. However, he realizes now that he has not been giving the
manual a high enough priority, and he wants to work with the rest of us
to bring the manual to a successful completion as soon as possible.
Guy proposed the following division of labor: I will orchestrate the
debate on the remaining open issues and will attempt to gain a consensus
(or at least a decision) on each of them. On some of these issues, I will
be counting heavily on Gabriel, Wienreb, and Moon to help develop and
debug proposals. I will also take responsibility for final cleanup and
editing on the new Package and Error chapters.
In the meantime, Guy will finish up the editing on all those old issues
that require only editing. As new decisions are reached, Guy will edit
them into the manual. He will not attempt to play a major role in the
network debates, though of course he will express his opinion on those
issues he feels strongly about.
Over the next day or two, Guy and I will be developing a list of the
remaining controversial issues that have to be dealt with.
The key to all of this is that Guy and I have to keep our channels of
communication open, to each other and to the rest of the Common Lisp
community. Given that, I think this plan can work, and will get the job
done faster and better than if either of us tried to do the job alone.
At least, I am willing to give it one more try.
I will be sending a message to the Common Lisp mailing list soon,
to describe the new division of labor and to begin discussion of some of
the issues.
-- Scott
∂25-May-83 2125 Guy.Steele@CMU-CS-A Finishing the manual
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 25 May 83 21:25:05 PDT
Date: 26 May 1983 0017-EDT (Thursday)
From: Guy.Steele@CMU-CS-A
To: Scott.Fahlman <FAHLMAN@CMU-CS-C>, moon%scrc-tenex@MIT-MC,
dlw%scrc-tenex@MIT-MC, declisp@CMU-CS-C, vanroggen@CMU-CS-C,
rpg@SU-AI, Allen.Newell@CMU-CS-A, John.McDermott@CMU-CS-A,
raj.reddy@CMU-CS-A
Subject: Finishing the manual
First, of all, I would like to offer my abject apologies for my lack
of communication. I have a bug that I much prefer to present polished
work fully done than to dribble out partial drafts. Also, given the
choice between processing mail and answering it when there is not time
for both, I tend to give higher priority to processing it. I feel very
badly that this has given you all the feeling of hanging.
>From my viewpoint I don't think the situation is as bad as it probably
seems from yours. My predictions of a month ago went badly awry. Let me
raise one point in defense and then let it drop: the volume of mail,
measured in pages, of the Common LISP discussion for the last month
(mid-April to now) has exceeded in volume the mail for the entire six
months before that (mid-October to mid-April, that is, since before the
Laser edition).
Here is a proposal for action (I have already discussed this with Scott).
I would like to ask Scott to undertake the task of preparing the ERROR
and PACKAGE chapters according to the discussions of the last month.
(Besides technical problems, much of the work is simply preparing it
properly for SCRIBE. There are dozens of magic macros.) In addition,
I would like to transfer to him the task of coordinating quick resolution
of outstanding trivial problems. I will continue to track mail
on trivial problems. Additionally, I am going into super burnout mode
betwen now and Tuesday to get completely caught up on all old issues,
that is, all comments and discussion as of mid-April. I will also
work on the problem of an improved index. After that point, we will see
what is the best strategy to pursue on resolving any remaining issues.
By the afternoon of Thursday, May 26, I hope to have completely gone over
Moon's list of outstanding problems and send to you all a note on my
perception of the status of each.
I do not want the Common LISP effort to fall apart. To answer Scott's
apprehensions, I state firmly that while there is a copyright notice in
my name on the text, this was, as previously agreed, purely for the purpose
of maintaining control of the document in the hands of the Common LISP
group rather than letting it pass de facto into the hands of any one
subgroup. The work was supported by university funding and it would be
wholly unethical for me or for anyone to block use of the text for selfish
reasons. If it becomes apparent that the Common LISP effort is best
served by my passing "control" of the manual into other hands, then I will
do so. This will almost certainly happen eventually, but I do not believe
that the time is now. I suggest that the situation be re-evaluated in
one week's time.
--Guy
∂06-Jun-83 0959 RPG Issues raised by MOON and DLW
∂28-May-83 1150 FAHLMAN@CMU-CS-C Issues raised by MOON and DLW
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 28 May 83 11:49:57 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 28 May 83 14:51:06 EDT
Date: Sat, 28 May 1983 14:51 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: steele@CMU-CS-C
Cc: moon%scrc-tenex@mit-mc, dlw%scrc-tenex@mit-mc, rpg@su-ai,
fahlman@CMU-CS-C
Subject: Issues raised by MOON and DLW
Guy,
I have now read over your response to the shopping list from Symbolics,
and all of the things that you list as "OK by me" are also OK by me,
with the following exceptions and comments:
41: I would really like COND to be the special form in here, and maybe
also AND and OR, with IF as the macro. Tradition, and that's the way we
have it implemented. I suppose that program-understanding programs
would be happier with IF, but hairy COND forms become pretty awful when
expanded into IF.
42: I agree with the idea to allow implementation-dependent functions
but not special forms in macro-expansions. At least, I'e been unable to
come up with an example where this screws us. HOWEVER, we'd better run
this by the crtics gallery, to make sure we're not missing anything
important, so I would keep this one as "controversial".
49: On DEFCONSTANT, go ahead and flush the error, but I object fairly
strongly to the := suggestion. It's a flaw that we don't have any good
way to leave a documented DEFVAR unbound, but I've never needed this in
practice.
80: The proposal to change LOOP to make a BLOCK NIL around the tagbody
has already passed by Common Lisp with no objection, and it is clearly
necessary. I would take this as being approved.
101: The proposal to make global DECLARE into PROCLAIM, thus solving the
ambiguity problem for SPECIAL, has already flown and is in fact already
implemented in my new lexical interpreter. But let's call this
controversial and let me run it by the masses one more time, since I'm
not sure everyone publically agreed that it was resolved.
168: BSG's proposal to flush MAXPREFIX and MAXSUFFIX and to change the
counting on MISMATCH :FROM-END were unopposed and look very good to me.
I'd treat this as adopted.
203: I'll have to go look up Bawden's proposal on DEFSTRUCT slot
options, but if this is the one where he proposes an :INIT keyword, that
is fine with me. But not if it's named := .
210: I think I've got a problem with APPLYHOOK. This should be
considered controversial and should not go in yet. Could MOON or DLW
send out a definite proposal instead of indirecting through the 4.0
release notes? In any event, I am opposed to having CLM specify this
business about the volatility of &rest args -- I would hope that
Symbolics plans to fix this someday. (Only "cheat" in compiled code,
and have the compiler tell if such cheating is OK for a given function,
or something like that.)
211: It seems to me that the reason we're ahving trouble with Constantp
is because it's a confused and relatively useless function that ought to
be punted. There are a number of behaviors that you might want from
such a function, depending on what it's for, and any of those behaviors
is easibly obtainable by a user-written function.
233: I am enthusiastic about the :RECURSIVE keyword to the READ family.
However, I would change it to :CALLED-RECURSIVELY or :INTERNAL-CALL or
something.
241: I think that the source of the confusion here is the use of the
terms "left-parenthesis" and "right-parenthesis". I can't ever remember
(and I'm not sure if there is a global authority on this) whether the
left paren is the one that is on the left of a list, or whether it's the
one that points to the left. How about "open-paren" and "close-paren"?
245: I agree with Guy that echoing should be done here, regardless of
who may have barfed earlier. (One free barf-bag and a ticket to Monty
Python's Meaning of Life if that person repeats the act.)
254: Sounds like we all favor Fortran-like ~E, ~F, and ~G floating-point
and/or some form of ~$. All we need now is a concrete proposal.
Anything halfway reasonable would be an improvement. Any volunteers?
RPG, maybe?
261: The exact form of the Y or N query should be left to the
implementation, but some wording indicating that the user should not
include "(Y or N)" because the system will supply some appropriate
prompt would be good.
267: Looks like there are N controversial points surrounding the file
system business. I'd like to see a new concrete proposal from someone.
Volunteers? Symbolics may have the strongest opinions here, so maybe
they should try to produce a specific proposal, if they can keep it
simple.
My one personal gripe about this, which I've raised N times, is
that the concepts of HOST and NAMING-PROTOCOL should not be
muddled, but should be separate slots. A host is like "CMUC" or
"CMU-CS-WOMBAT" while a naming protocol is like "Tops-20" or "unix" or
"Spice-CFS". You can maybe determine the naming protocol from the host
name in an implementation-specific or site-specific way, but that's no
reason to smash the two together. It is the naming protocol that the
parsing function needs to know.
All "controversial" issues not mentioned here will either result in a
proposal before the Common Lisp mailing list or in a private attempt on
my part (cc at least to all of you) to get the proposer to reconsider
whether the change in question is a good idea.
-- Scott
∂06-Jun-83 0959 RPG Ok-by-me's
∂28-May-83 1314 FAHLMAN@CMU-CS-C Ok-by-me's
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 28 May 83 13:14:09 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 28 May 83 16:14:45 EDT
Date: Sat, 28 May 1983 16:14 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Dick Gabriel <RPG@SU-AI>
Cc: GLS@SU-AI
Subject: Ok-by-me's
In-reply-to: Msg of 28 May 83 1308 PDT from Dick Gabriel <RPG at SU-AI>
Dick,
Looks like Guy is eager to do the ~F,~G,~E,~$ proposal, so my suggestion
that you should think about this is inoperative.
-- Scott
∂06-Jun-83 0959 RPG Issues raised by MOON and DLW
∂28-May-83 1446 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN Issues raised by MOON and DLW
Received: from MIT-MC by SU-AI with TCP/SMTP; 28 May 83 14:27:40 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Sat 28-May-83 17:30:52-EDT
Date: Saturday, 28 May 1983, 17:22-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Issues raised by MOON and DLW
To: Scott E. Fahlman <Fahlman%CMU-CS-C@SU-DSN>
Cc: steele%CMU-CS-C@SU-DSN, moon%SCRC-TENEX%MIT-MC@SU-DSN,
dlw%SCRC-TENEX%MIT-MC@SU-DSN, rpg@su-ai
In-reply-to: The message of 28 May 83 14:51-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
This message will be a bit longer than necessary, since I'm not going to
delete any of Scott's message from it, for archival purposes.
Date: Sat, 28 May 1983 14:51 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
Guy,
I have now read over your response to the shopping list from Symbolics,
and all of the things that you list as "OK by me" are also OK by me,
I haven't seen this list. Should I?
with the following exceptions and comments:
41: I would really like COND to be the special form in here, and maybe
also AND and OR, with IF as the macro. Tradition, and that's the way we
have it implemented. I suppose that program-understanding programs
would be happier with IF, but hairy COND forms become pretty awful when
expanded into IF.
See second paragraph below.
42: I agree with the idea to allow implementation-dependent functions
but not special forms in macro-expansions. At least, I'e been unable to
come up with an example where this screws us. HOWEVER, we'd better run
this by the crtics gallery, to make sure we're not missing anything
important, so I would keep this one as "controversial".
We have large numbers of macros that expand into
implementation-dependent special forms. This is unavoidable. Is this
restriction intended to apply to all macros, or only to macros that are
documented in the Common Lisp manual? If the latter, I'd have to check
carefully, but it is perhaps possible that none of them need to expand
into implementation-dependent special forms.
I really believe that the attempt to limit the number of special forms
is inherently unworkable. I do have a "template" scheme, partly
borrowed from Interlisp Masterscope, that makes it possible for a
portable program to "understand" certain limited kinds of
implementation-dependent special forms (basically ones that don't change
the flow of control in "strange" ways). It can handle most forms of
binding, setting, and evaluation of subforms. SETF and related tools
are based on this.
49: On DEFCONSTANT, go ahead and flush the error, but I object fairly
strongly to the := suggestion. It's a flaw that we don't have any good
way to leave a documented DEFVAR unbound, but I've never needed this in
practice.
I guess I need to see the proposed change. We get around the problem with
unbound documented defvars by never documenting any variables, except with
comments, which isn't really very good.
80: The proposal to change LOOP to make a BLOCK NIL around the tagbody
has already passed by Common Lisp with no objection, and it is clearly
necessary. I would take this as being approved.
Yes.
101: The proposal to make global DECLARE into PROCLAIM, thus solving the
ambiguity problem for SPECIAL, has already flown and is in fact already
implemented in my new lexical interpreter. But let's call this
controversial and let me run it by the masses one more time, since I'm
not sure everyone publically agreed that it was resolved.
Sure.
168: BSG's proposal to flush MAXPREFIX and MAXSUFFIX and to change the
counting on MISMATCH :FROM-END were unopposed and look very good to me.
I'd treat this as adopted.
Yes. Unless there are new rationales for them that I haven't heard.
203: I'll have to go look up Bawden's proposal on DEFSTRUCT slot
options, but if this is the one where he proposes an :INIT keyword, that
is fine with me. But not if it's named := .
I don't remember.
210: I think I've got a problem with APPLYHOOK. This should be
considered controversial and should not go in yet. Could MOON or DLW
send out a definite proposal instead of indirecting through the 4.0
release notes?
I'll send something under separate cover, after I go look at the code.
But it's really very simple.
In any event, I am opposed to having CLM specify this
business about the volatility of &rest args -- I would hope that
Symbolics plans to fix this someday. (Only "cheat" in compiled code,
and have the compiler tell if such cheating is OK for a given function,
or something like that.)
We have very long-term plans to fix this, but it isn't easy and we can't
promise any sort of schedule. Furthermore the plan is based on
exploiting some special hardware we have in the machine, which suggests that
other implementations will find this problem considerably harder to
solve. What do your implementations do?
It is essentially impossible to do it at compile time, because many
&rest arguments are passed as arguments to functions which in fact will
only use them in a "downward" way, but the compiler doesn't know that.
The efficiency cost of being conservative there would be too high, at
least in our implementation where the ratio of the cost of CONS to the
cost of CDR is very high. This is certainly a wart, but I'm not sure
what to do about it. Possibly a declaration or two ways of spelling
&REST.
211: It seems to me that the reason we're ahving trouble with Constantp
is because it's a confused and relatively useless function that ought to
be punted. There are a number of behaviors that you might want from
such a function, depending on what it's for, and any of those behaviors
is easibly obtainable by a user-written function.
Not so! The way you tell whether a symbol has been declared as a constant
with DEFCONSTANT is implementation-dependent. Furthermore the set of
self-evaluating data types is implementation-dependent, because of extensions
to the standard language. I don't think the function is useless, certainly
not in the kind of program-manipulation code I've been writing recently.
The confusion I think derives from one thing: does this function operate
on forms or on objects? It seems clear from its presence in the eval
chapter that it should operate on forms, which means that it should be true
of lists whose car is QUOTE. But its English description isn't written that
way. This seems resolvable.
Incidentally I also found a need for a function called VARIABLEP. This is
not (NOT (CONSTANTP ...)), rather it is true for "things you can bind", which
as it happens is equivalent to (AND (SYMBOLP X) (NOT (CONSTANTP X))). But
the function may be worth having separately anyway. Not a big deal, since
we will have it internally anyway, but I thought I'd mention it in case it
seems appropriate to make it standardly available.
233: I am enthusiastic about the :RECURSIVE keyword to the READ family.
However, I would change it to :CALLED-RECURSIVELY or :INTERNAL-CALL or
something.
I'd have to see the proposal.
241: I think that the source of the confusion here is the use of the
terms "left-parenthesis" and "right-parenthesis". I can't ever remember
(and I'm not sure if there is a global authority on this) whether the
left paren is the one that is on the left of a list, or whether it's the
one that points to the left. How about "open-paren" and "close-paren"?
I've never heard of this confusion before. ( is a left parenthesis and
) is a right parenthesis. I would hesitate to guess which way either of
those is said to "point". There is one place on page 241 where "left"
and "right" are interchanged. Is there more confusion there than just
that typographical error? Since every place else in the manual I
can see says "open" and "close", I guess this terminology should be used
consistently and "left" and "right" should be removed.
245: I agree with Guy that echoing should be done here, regardless of
who may have barfed earlier. (One free barf-bag and a ticket to Monty
Python's Meaning of Life if that person repeats the act.)
This is about read-char? I agree that the "simple" functions should take
care of echoing, input editing, wakeup control, and so forth in whatever
implementation-dependent way is appropriate (and this is -damned- implementation
dependent!) For now, screen editors will have to read their commands in
an implementation-dependent way. We might consider standardization of
more detailed interactive I/O (both keyboard and screen) for the second
edition.
254: Sounds like we all favor Fortran-like ~E, ~F, and ~G floating-point
and/or some form of ~$. All we need now is a concrete proposal.
Anything halfway reasonable would be an improvement. Any volunteers?
RPG, maybe?
Yes. I don't volunteer to write the proposal though. I think I've already
mailed out the documentation on the present Lisp machine/Maclisp/NIL ~$
(it's too recent to be in the Chine Nual) and I could mail it out again
if you want. The present Lisp machine FORMAT has nothing of worth to
offer for ~E,~F,~G.
261: The exact form of the Y or N query should be left to the
implementation, but some wording indicating that the user should not
include "(Y or N)" because the system will supply some appropriate
prompt would be good.
Good.
267: Looks like there are N controversial points surrounding the file
system business.
Does this refer to everything in chapter 22 or just pathnames?
I'd like to see a new concrete proposal from someone.
Volunteers? Symbolics may have the strongest opinions here, so maybe
they should try to produce a specific proposal, if they can keep it
simple.
Maybe Dan can do this, he'll have to say, but I don't think I can find the
time and energy to deal with this right now, with all the other things
I'm trying to stay on top of.
My one personal gripe about this, which I've raised N times, is
that the concepts of HOST and NAMING-PROTOCOL should not be
muddled, but should be separate slots. A host is like "CMUC" or
"CMU-CS-WOMBAT" while a naming protocol is like "Tops-20" or "unix" or
"Spice-CFS". You can maybe determine the naming protocol from the host
name in an implementation-specific or site-specific way, but that's no
reason to smash the two together. It is the naming protocol that the
parsing function needs to know.
All "controversial" issues not mentioned here will either result in a
proposal before the Common Lisp mailing list or in a private attempt on
my part (cc at least to all of you) to get the proposer to reconsider
whether the change in question is a good idea.
-- Scott
∂06-Jun-83 1000 RPG Changes to Laser edition for APPLYHOOK
∂28-May-83 1513 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN Changes to Laser edition for APPLYHOOK
Received: from MIT-MC by SU-AI with TCP/SMTP; 28 May 83 15:12:04 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Sat 28-May-83 18:12:41-EDT
Date: Saturday, 28 May 1983, 18:04-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Changes to Laser edition for APPLYHOOK
To: Fahlman%CMU-CS-C@SU-DSN
Cc: Steele%CMU-CS-C@SU-DSN, RPG@SU-AI, Moon%SCRC-TENEX%MIT-MC@SU-DSN,
DLW%SCRC-TENEX%MIT-MC@SU-DSN
Rationale:
When stepping through an interpreted program, it is desirable to be able
to pause before each evaluation, to pause after each evaluation so that
the value can be examined or changed. These operations can be done with
the evalhook feature. It is also desirable to pause before invoking
a function (whether a user function or a system function), so that the
values of the arguments may be examined or modified. This requires the
applyhook feature, or else requires duplicating an unnecessarily large
part of the EVAL function.
The applyhook feature catches only APPLY operations done by EVAL. It
does not catch APPLY done in other parts of the interpreter (i.e. by
special forms: CATCH-ALL and UNWIND-ALL are the only ones in Table 5-1
that would do an APPLY), nor does it catch APPLY or FUNCALL operations
done by functions (MAPCAR for instance). Stepping through APPLY
operations done by a function such as MAPCAR are best done by
intercepting the call to MAPCAR, using the apply hook, and substituting
a different first argument.
Note:
The writeups for APPLYHOOK and *APPLYHOOK* should be largely copied
from the writeups for EVALHOOK and *EVALHOOK*. I have not made any
attempt to do this, but have just indicated the differences.
New variable *APPLYHOOK*: (analogous to *EVALHOOK*)
When non-NIL, EVAL behaves in a special way. Whenever it is about to
apply a function to the values of the function's arguments, which have
already been evaluated, instead it calls the value of *APPLYHOOK* with
two arguments: the function and its list of arguments. Whatever values
the hook function returns are taken as the results.
The list of arguments is just like an &rest argument in its volatility.
If the hook function just calls APPLY on its first two arguments, EVAL
would behave in its normal way except a little slower. [Of course the
preceding sentence isn't true in a lexical interpreter, where the
internal environment-taking APPLY isn't accessible to the user except
through the APPLYHOOK function, below.]
[The apply hook function gets additional "env" arguments just like the
eval hook function.]
EVAL binds both *EVALHOOK* and *APPLYHOOK* to NIL around calls to either of them.
EVALHOOK takes an extra argument:
*APPLYHOOK* is bound to the third argument (before the "&rest env"), a function
or NIL.
New function APPLYHOOK: (analogous to EVALHOOK)
The arguments are function, arglist, evalhook, applyhook (&rest env).
This function is completely analogous to EVALHOOK and is to be called by
*APPLYHOOK* functions in the same way that EVALHOOK is to be called by
*EVALHOOK* functions, to "jump back into the interpreter".
Macros and special forms:
*APPLYHOOK* does not affect the invocation of a macro expansion function.
Currently in the Lisp machine *APPLYHOOK* affects special forms; the function
and argument list passed to the hook function are such that using APPLY on
them will do the right thing. SPECIAL-FORM-P will be true of the function.
The argument-list is usually just the cdr of the form being evaluated, but
this isn't guaranteed and depends on the particular special form. Exceptions:
special forms that are really implemented as macros are not affected by
*APPLYHOOK*, nor is the QUOTE special form.
I am amenable either to leaving this the way it is or to saying that
*APPLYHOOK* has no effect on special forms. Since the Lisp machine allows
"functions with "e arguments" we will probably have *APPLYHOOK*
still affect them, however they would not appear in any Common Lisp programs,
and I think we can arrange for it not to affect "real special forms."
∂06-Jun-83 1000 RPG Issues raised by MOON and DLW
∂28-May-83 1548 FAHLMAN@CMU-CS-C Issues raised by MOON and DLW
Received: from SU-DSN by SU-AI with PUP; 28-May-83 15:48 PDT
Received: From CMU-CS-C by SU-DSN.ARPA; Sat May 28 15:10:46 1983
Received: ID <FAHLMAN@CMU-CS-C>; 28 May 83 18:09:15 EDT
Date: Sat, 28 May 1983 18:09 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: David A. Moon <Moon%SCRC-TENEX@MIT-MC>
Cc: dlw%SCRC-TENEX@MIT-MC, rpg%su-ai@SU-DSN, steele@CMU-CS-C
Subject: Issues raised by MOON and DLW
In-reply-to: Msg of 28 May 1983 17:22-EDT from David A. Moon <Moon%SCRC-TENEX at MIT-MC>
The response by Guy went out as mail (I think you were an addressee, but
I've deleted that part of it) and is also sitting on CMUC as
PRVA:<SLISP.SCL>LASER.REPLY. I assumed that you had put it there, but I
see that it was Guy who did. Anyway, have a look.
We have large numbers of macros that expand into
implementation-dependent special forms. This is unavoidable. Is this
restriction intended to apply to all macros, or only to macros that are
documented in the Common Lisp manual? If the latter, I'd have to check
carefully, but it is perhaps possible that none of them need to expand
into implementation-dependent special forms.
This only applies to those macros in the manual. Let me know if you
find any screw cases, given this restriction. I think the restriction
makes sense, if there are no screws to be found.
210: I think I've got a problem with APPLYHOOK. This should be
considered controversial and should not go in yet. Could MOON or DLW
send out a definite proposal instead of indirecting through the 4.0
release notes?
I'll send something under separate cover, after I go look at the code.
But it's really very simple.
Well, we don't really call APPLY from within EVAL, exactly. But maybe
if this hook is non-null I can arrange to. I'll have to see the
proposal, as they say.
Right now we just cons &rest args. We don't presently have CDR-coding
anyway. Slow, but I would be unwilling to gain speed by handing the
user a volatile pseudo-list, unless the system could determine when to
de-volatilize it. That just looks too treacherous to me.
Not so! The way you tell whether a symbol has been declared as a constant
with DEFCONSTANT is implementation-dependent. Furthermore the set of
self-evaluating data types is implementation-dependent, because of extensions
to the standard language. I don't think the function is useless, certainly
not in the kind of program-manipulation code I've been writing recently.
The confusion I think derives from one thing: does this function operate
on forms or on objects? It seems clear from its presence in the eval
chapter that it should operate on forms, which means that it should be true
of lists whose car is QUOTE. But its English description isn't written that
way. This seems resolvable.
There are two notions muddled together here. One is whether a symbol is
a constant. We need a portable test for that. The other is whether an
object (or form) can be fed to EVAL and produce itself. It is EVAL's
business how it does that efficiently -- certainly not by calling
something that checks for ''foo or whatever. If the user needs to know
this (why would he?) he can see if (eq x (eval x)), no? Or EQUALP, or
whatever it is that he really wants to know.
Guy has already popped up with the ~E, ~F, ~G proposal, but I now have
to go find a Fortran manual to understand it. He also plans to propose
something for ~S, so that's taken care of.
If no other volunteer appears, I will take a crack at fixing up
pathnames a bit. I was just trying to avoid another situation where you
Symbolics folks end up spending more time criticizing my proposal for
not be what you would have written than you would have spent writing it.
I had the impression that you had some definite ideas about how this
ought to go. Then again, maybe this time I'll get it right on the first
try.
-- Scott
∂06-Jun-83 1001 RPG Changes to Laser edition for APPLYHOOK
∂28-May-83 1908 FAHLMAN@CMU-CS-C Changes to Laser edition for APPLYHOOK
Received: from SU-DSN by SU-AI with PUP; 28-May-83 19:07 PDT
Received: From CMU-CS-C by SU-DSN.ARPA; Sat May 28 18:28:23 1983
Received: ID <FAHLMAN@CMU-CS-C>; 28 May 83 21:26:40 EDT
Date: Sat, 28 May 1983 21:26 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: David A. Moon <Moon%SCRC-TENEX@MIT-MC>
Cc: DLW%SCRC-TENEX@MIT-MC, RPG%SU-AI@SU-DSN, Steele@CMU-CS-C
Subject: Changes to Laser edition for APPLYHOOK
In-reply-to: Msg of 28 May 1983 18:04-EDT from David A. Moon <Moon%SCRC-TENEX at MIT-MC>
OK, I am in favor of APPLYHOOK given a suitably cleaned-up version of the
documentation. I may have to change around my lexical evaluator a bit,
but I'll get it in.
-- Scott
∂06-Jun-83 1002 RPG Issues raised by MOON and DLW
∂28-May-83 1908 Moon%SCRC-TENEX@MIT-MC Issues raised by MOON and DLW
Received: from SU-DSN by SU-AI with PUP; 28-May-83 19:08 PDT
Received: From MIT-MC by SU-DSN.ARPA; Sat May 28 18:38:35 1983
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Sat 28-May-83 21:38:52-EDT
Date: Saturday, 28 May 1983, 21:30-EDT
From: David A. Moon <Moon%SCRC-TENEX@MIT-MC>
Subject: Issues raised by MOON and DLW
To: Scott E. Fahlman <Fahlman@CMU-CS-C>
Cc: dlw%SCRC-TENEX@MIT-MC, rpg%su-ai@SU-DSN, steele@CMU-CS-C
In-reply-to: The message of 28 May 83 18:09-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: Sat, 28 May 1983 18:09 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
From: Moon
Not so! The way you tell whether a symbol has been declared as a constant
with DEFCONSTANT is implementation-dependent. Furthermore the set of
self-evaluating data types is implementation-dependent, because of extensions
to the standard language. I don't think the function is useless, certainly
not in the kind of program-manipulation code I've been writing recently.
The confusion I think derives from one thing: does this function operate
on forms or on objects? It seems clear from its presence in the eval
chapter that it should operate on forms, which means that it should be true
of lists whose car is QUOTE. But its English description isn't written that
way. This seems resolvable.
There are two notions muddled together here. One is whether a symbol is
a constant. We need a portable test for that. The other is whether an
object (or form) can be fed to EVAL and produce itself. It is EVAL's
business how it does that efficiently -- certainly not by calling
something that checks for ''foo or whatever. If the user needs to know
this (why would he?) he can see if (eq x (eval x)), no? Or EQUALP, or
whatever it is that he really wants to know.
My interpretation of CONSTANTP is that it tells you whether a form always
evaluates to the same value. I mean by definition, not by elaborate
program analysis. It isn't true of (LET ((X 0)) (DOTIMES (Y 100 X) (INCF X Y)))
nor even of (+ 2 2). It's not whether an object is self-evaluating,
and not whether a symbol has been declared with DEFCONSTANT. So there are
three notions muddled together here. But let's get it straight that we're
talking about a function that is in the language because it's useful to users,
or to the macros that they write. We're not talking about a function that
is called by EVAL in one place.
If no other volunteer appears, I will take a crack at fixing up
pathnames a bit. I was just trying to avoid another situation where you
Symbolics folks end up spending more time criticizing my proposal for
not be what you would have written than you would have spent writing it.
I had the impression that you had some definite ideas about how this
ought to go. Then again, maybe this time I'll get it right on the first
try.
Well, we do have a working multi-host generic pathname system, along
with some ideas of what's wrong with it. And we do have some specific
statements of things that are unworkable about the one in the laser
manual, which might be summed up as slavish, but inexact, copying of (an
older version of) the Lisp machine pathname system without really
understanding it, and logical pathnames that can't be used. Sections 22.2ff
are okay except for maybe a few small nits. But I don't feel able to design
a whole new pathname system right now.
∂06-Jun-83 1002 RPG Non-ballot
∂28-May-83 1934 FAHLMAN@CMU-CS-C Non-ballot
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 28 May 83 19:33:51 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 28 May 83 22:34:02 EDT
Date: Sat, 28 May 1983 22:34 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: moon%scrc-tenex@mit-mc, dlw%scrc-tenex@mit-mc
Cc: steele@CMU-CS-C, fahlman@CMU-CS-C, rpg@su-ai
Subject: Non-ballot
There are a number of things that appeared in your initial list of
suggestions that, in my opinion, might want to be dropped instead of
appearing on a ballot to Common Lisp. At least, I would like you to
consider dropping these. Any that you feel strongly about keeping will
appear on a ballot, but the more of these issues we can settle without
that, the quicker we will be able to converge. So let me know which of
these you are now willing to drop, if any.
I am assuming that you have read Guy's LASER.REPLY file.
Page 0: I agree that the language would be somewhat better off with
somewhat fewer mumble-p predicates, but I am really inclined to let
sleeping dogs lie on this issue. If you do want to pursue it, please
indicate which predicates should go.
Page 25: I can't believe that a package could ever be a raw hash-table
under the current package plan. I would always be a structure
containing one or more hash-tables, some lists, nicknames, and other
things. So this proposal is now obsolete, I think.
Page 37: In the manual, COERCE takes ARGUMENT, then RESULT-TYPE. Since
the other order is not clearly superior, let's let it be.
Page 38: Coercing of characters to integers is not a very useful
operation in portable code if the langauge spec does not specify the
correspondence (and Common Lisp does not). Do you still want to propose
that we add this coercion? I'm not particularly opposed, I just worry
that users will find it too easy to inadvertently do non-portable things
if given this coercion.
Page 87: Guy seems to have come up with a pretty good reason not to let
TAGBODY drop through with the last value: the last form might be a tag.
Do you still believe that this is the best thing to do? I don't.
Page 99: Do you still think that destructuring DEFMACRO is essential? I
really dislike mixing destructuring and &mumble in the same variable
list. I suppose that this can be made unambiguous, by saying that the &
words are only recognized at top-level in the list, and as soon as one
is seen, no more destructuring is allowed, but that's pretty ugly. What
if we had two flavors of defmacro, one with a lambda-like list and one
with destructuring? Or am I being too conservative here?
Pages 103-105: If you want some sort of declaration (or proclamation)
form whose scope is local to a file, or sometimes is, or whatever,
please make a specific proposal.
Page 164: "Should there be a mroe concise way..." Guy doesn't think so,
neither do I. Do you have a specific proposal to make?
Page 166: "There should be a way..." Again, a proposal would be needed
here if you want to press the issue. I see no great need for an
additional function to do this.
Page 167: I agree with Guy that NSUBSTITUTE should just parallel the
other similar forms.
Page 192: Flush RESET-FILL-POINTER, add FILL-POINTER and SETF of it. I
would be inclined to let it be, but I don't care much either way. Is it
worth the effort?
Page 204: Are you proposing a :named keyword to MAKE-ARRAY, with the
name as the arg, or what?
Page 212: I agree with Guy that to add a special case for not advancing /
and * would be more confusing than not to add this special case.
Page 221: I thought we had voted to flush *IBASE* and just to use #O and
friends to get particular non-decimal constants in. Portable code
should not contain sections that use octal (or whatever) wholesale. If
you really want *IBASE* in Common Lisp, I will give in on this, but at
least we want a strong warning that this should not be used for whole
files or around large sections of code. We've got to break the dead
grip of octal someday.
Page 238: Presumably you have some use in mind for *PRINT-READABLY* ?
I'm curious what you think it is good for.
As I said earlier, if you really want any of these things, I'll put them
on the ballot, though I will oppose some of them. I'm just trying to
keep the number of issues to be publically debated down to a manageable
size.
-- Scott
∂06-Jun-83 1003 RPG cmuc:prva:<slisp.scl>laser.reply
∂28-May-83 1947 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN cmuc:prva:<slisp.scl>laser.reply
Received: from MIT-MC by SU-AI with TCP/SMTP; 28 May 83 19:46:47 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Sat 28-May-83 22:49:08-EDT
Date: Saturday, 28 May 1983, 22:40-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: cmuc:prva:<slisp.scl>laser.reply
To: Steele%CMU-CS-C@SU-DSN
Cc: Fahlman%CMU-CS-C@SU-DSN, RPG@SU-AI, DLW%SCRC-TENEX%MIT-MC@SU-DSN,
Moon%SCRC-TENEX%MIT-MC@SU-DSN
Discussion of some selected things from that file:
* 38: Coercing of characters to integers should probably be allowed too. -- DLW [not done]
{controversial}
---
I don't think coercion of characters to integers should be allowed, because
how do you know whether you want the char-code or what. Dan was probably
just stuck in our old mindset from not having character objects on the Lisp
machine (we have them now, but only Common Lisp uses them; Zetalisp doesn't).
Coercion of characters to strings, however, I believe is useful.
---
* 49: Also add a note saying how to define a documented variable without giving it
a value (SETF of DOCUMENTATION I guess, bleagh). -- Moon [not done]
---
I'd rather flush variable documentation entirely than require an = between
the variable name and the initial value in the usual case. Maybe SETF of
DOCUMENTATION really is the least ugly way.
---
* 71: The query: good problem. Make it legal to pass unknown keywords?? -- DLW
{controversial}
---
Is my proposed :allow-other-keys kludge an acceptable solution?
---
* 87: a tagbody that drops off the end should return the value(s) of the
last form, rather than nil, since many applications would otherwise need
to wrap a block around it; a simple looping construct that turns into -- Moon [not done]
(TAGBODY initialization NEXT iteration END return-value) is an example.
{Controversial. What is the value in the case
(TAGBODY form1 form2 tag) ? The value of form2, in the drop-through case?
What about when one does a GO to the tag?}
---
I agree now that returning NIL if tagbody falls of the end is better.
Well, all the tagbodys I ever write always have blocks around them it seems,
so maybe I should just be using prog anyway. Except there's no named-prog.
---
182: [gloss] subst is required to make a complete copy of the tree.
I'm not sure I'm happy about this, also nothing is said about whether sublis
makes a copy or not. --Moon
{On the contrary, the second sentence explicitly states that the
result of SUBST may share with the argument tree. Also,
examine the sample code for SUBST. Will clarify SUBLIS.}
---
Sorry about that, that's what I get for reading just the source compare
and not the full text. I checked the full text and it's quite explicit.
---
* 192g: flush reset-fill-pointer, add fill-pointer, and allow setf of fill-pointer. -- Moon
[not done]
{controversial}
---
Really??
---
* 204: How does defstruct create named vectors (second to last paragraph)
if neither make-array nor make-simple-vector takes a :named keyword? It would
be nice for defstruct to be written entirely in the portable language, not
in some magic implementation-dependent language. -- Moon [not done]
{controversial. Make a proposal? Is make-array the right place to
do this?}
---
I think the right thing is for defstruct to call MAKE-VECTOR with the :NAMED
keyword; value is the name. Since MAKE-ARRAY should logically be able to do
anything that MAKE-VECTOR can do, it has to accept a :NAMED keyword also;
probably the array is required to be one-dimensional (unless it has a leader,
but that is going outside of Common Lisp).
---
* 212: When no values are returned, /, //, ///, *, **, and *** should not
be advanced, since nothing was printed. Likewise when execution is
aborted, they should not be advanced. Of course when printing is aborted
they should advance. Since these variables are for people, not for
programs, it is more important that * be the last thing that was printed
than that + and * be kept in sync. -- Moon [not done]
{controversial. I disagree -- parallelism is important, and I think that
/, //, /// should always advance.}
---
Let's be explicit here. If what you think is the following, then not only
are we completely in agreement but (I just checked) that's what our code
does now, modulo having only /, not // and ///.
+, ++, +++ advance if a form was entered. They advance if you
abort out of evaluating, but not if you abort out of reading.
They're funny in that they don't advance until after evaluating,
but they do advance whether or not the evaluation is completed.
/, //, /// advance if evaluation is completed, no matter how many
values are returned.
*, **, *** advance if a value is printed, i.e. evaluation completed
and at least one value was returned. They advance even if printing
is aborted.
This means that there is no guaranteed parallelism between any pair of the
three values +, /, and *. On the other hand, there is guaranteed parallelism
between each of them and what you see on your screen, which I think is much
more important (this was the motivation for our changing a while back so
that *,**,*** wouldn't advance if no values were returned).
Note that I'm repudiating what I said about /,//,/// not advancing if no
values were returned. In retrospect that was wrong.
---
* 222: (table 21-1) # is a non-terminating macro character in the Lisp
machine now. If Common Lisp is going to have them, # should be one. -- Moon [not done]
{controversial}
---
The package system probably requires this, to make #: qualified names parse.
I believe strongly that such "internal qualified names" should be something
a little obscure-looking, and definitely shouldn't be :: (the other obvious
choice) because it doesn't look different enough from a single :.
---
* 233: (#=) It says the scope is "the outermost call to READ". Interaction
between recursive calls to READ is certainly mysterious. Probably there is
a kludge in BREAK to prevent the next READ from thinking it is called recursively.
I'd rather see a different function for macro-character functions that want
to read sub-expressions to call. This would unfortunately imply that
READ-DELIMITED-LIST is illegal for anything but a macro-character to call,
since it has to know which version of READ to use. If we don't add a separate
function, this mysteriosity should be carefully documented. -- Moon [not done]
{hard. I think a separate function will be needed. Alternatively,
how about an extra keyword :recursive to the input functions READ,
READ-PRESERVING-WHITESPACE, and READ-DELIMITED-LIST, which when
true specifies that a new ## scope is not to be made?}
243: Making READ-PRESERVING-WHITESPACE a function rather than a special
variable you bind around a call to READ is nice. However, it brings
up the same problem with recursive calls to READ as #= does (my comment
about that, extracted from my general Laser-edition comments, is enclosed
for reference). Suppose you do (READ-PRESERVING-WHITESPACE)'FOO<space>;
that should preserve the space just as if there were no quote. But if
the quote macro character is defined the way it is in the example on
page 236, this won't happen; the inner call to READ will swallow the space.
If the quote macro character isn't really defined that way, and that is
just an oversimplified pedagogical example, then how are users supposed to
define their own macros? I think the old Maclisp "TYIMAN" family of crocks
are still with us.--Moon [not done]
{Regarding the proposal for a :recursive keyword to READ, perhaps
it would also when true cause the "global preserve-whitespace flag"
not to be altered.}
---
Okay by me: add :recursive and have it affect the preserve-whitespace.
Of course you realize this means all those functions have to be changed
from optional arguments to keyword arguments. If that's unacceptable, make
new functions (only READ and READ-DELIMITED-LIST require two versions, since
the preserving-whitespace distinction isn't relevant on recursive calls,
and no other functions read "S-expression" syntax (as opposed to lines or
characters).
---
238: There should be the equivalent of SI:PRINT-READABLY, which if true causes the
printer to signal an error rather than printing something that READ cannot
understand. (E.g. #<, prinlevel cutoff) -- Moon [not done]
{Another printer variable?}
---
Extracted from a Lisp machine source file. Of course the names should be changed:
;; If this variable bound to non-NIL, then any attempt to print something which
;; cannot be read will signal a PRINT-NOT-READABLE error. Also, objects which
;; do not normally print in a readably, but are indeed able to, will then do so.
(DEFVAR PRINT-READABLY NIL)
; A macro for aiding in the printing of random objects.
; This macro generates a form which:
; 1. Uses the print-table to find the things in which to enclose your randomness.
; 2. (by default) includes the virtual address in the printed representation.
; 3. Obeys PRINT-READABLY
; Options are :NO-POINTER to suppress the pointer
; :TYPEP princs the typep of the object first.
; :FASTP <fastp> if the variable happens to be sitting around.
; Example:
; (DEFSELECT ((:PROPERTY HACKER :NAMED-STRUCTURE-INVOKE))
; (:PRINT-SELF (HACKER STREAM IGNORE IGNORE)
; (SI:PRINTING-RANDOM-OBJECT (HACKER STREAM :TYPEP)
; (PRIN1 (HACKER-NAME HACKER) STREAM))))
; ==> #<HACKER "MMcM" 6172536765>
---
* 240: I think not allowing a package prefix before a vertical-barred symbol
is a dead loss. This affects page 226 (where vertical bar is described)
also. -- Moon
{controversial}
---
Really? You have to switch to backslashes if you happen to want to refer
to an oddly-spelled symbol of another package? How inconsistent.
---
241: In the description of how to print arrays, I think you have left
and right confused. -- DLW
{No, I think it is correct. Examine it carefully.}
---
Son of a gun, I read that this afternoon and I thought it was wrong, and
now I read it again carefully and see that it's right after all. Maybe someone
came in while I was out to dinner and switched manual pages on me--that's
the trouble with looseleaf-bound manuals.
---
245: Does read-char echo on interactive streams? (Probably the answer
is "yes".) --DLW [not done]
{Sigh. Previously there was text to the effect that echoing is done
and people barfed at me. I think they were right at that time:
echoing is a property of the stream, or the interaction of the stream
and the function, not solely of the function.}
---
Yes, the interaction of the stream and the function, with the exact
modularity depending on the implementation. I think this is only
a matter of English, not a Lisp language issue.
---
* 252: ~:A and ~:S should only affect the printing of NIL given directly
as an argument, not the printing of NILs inside a printed list. This is
because these are for printing an object that is known to be a list, not
for printing data so it can be read compatibly into a N.I.L system. -- Moon [not done]
{controversial}
---
Is this really controversial? If we need a feature for printing NIL as ()
that should be a *PRINNIL* (ugh, bletch!) printer-control variable, not a
FORMAT operator. That feature was specifically put into FORMAT for formatting
purposes, not as a substitute for a printer control variable.
NIL (the language) treats NIL (the symbol) the same as everyone
else does these days. Change motivated by Common Lisp compatibility.
---
* 254: ~$ is highly useful and should be put in. Pending a concrete proposal,
I think Fortran ~E, ~F, ~G should be put in. I just looked at a Fortran
manual and they look reasonable, except that 1P should be the default scale
for E and G formats. ~$ is close to ~F but not identical, it would seem. I
doubt that anyone would mind changing "absolute goto" from ~G to ~@*. -- Moon
{controversial. I strongly urge the adoption of FORTRAN-like
floating-point formatting.}
---
Yes. We should definitely do this (need to see a proposal).
---
* 294: apropos should return a list of the symbols found; this can be quite useful.
RMS recently changed his apropos to take arguments [not done]
string &key package superiors inferiors dont-print predicate
Common Lisp might want to adopt something like this, with perhaps keywords
to filter to only variables, only functions. -- Moon
{controversial. Keywords look okay. There is the same problem as with
PPRINT: after the nice-looking stuff has been printed, do you want your
screen garbaged up with the returned list?}
---
Well, we are fixing this whole class of issues via the command processor.
We will no longer confound functions, which programs call, with commands,
which provide nice interfacing to users. At the same time, the two worlds
are very closely tied together, like Siamese twins.
Common Lisp should probably have APROPOS return (VALUES) but dump the
list into a variable, either APROPOS or *APROPOS*. PPRINT should also
return (VALUES).
---
* 298: In what package are the symbols that are elements of *features*? The
Lisp machine uses keywords currently, but compatibility is not an issue here
since the way you get to the list is different. -- Moon [not done]
{controversial}
---
I'm not sure but probably using keywords would cause the least trouble.
Unless it really makes sense to have two features with the same name,
in different packages (all the standard features would be lisp:). I would
be happy either way, perhaps lean about 2% toward non-keywords. But the
manual needs to say which it is.
---
∂06-Jun-83 1004 RPG :unspecific issues with pathnames
∂28-May-83 1954 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN :unspecific issues with pathnames
Received: from MIT-MC by SU-AI with TCP/SMTP; 28 May 83 19:54:42 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Sat 28-May-83 22:55:51-EDT
Date: Saturday, 28 May 1983, 22:47-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: :unspecific issues with pathnames
To: Steele%CMU-CS-C@SU-DSN
Cc: Fahlman%CMU-CS-C@SU-DSN, RPG@SU-AI, DLW%SCRC-TENEX%MIT-MC@SU-DSN
This text was extracted from the Release 4.0 notes. I hope you'll
forgive me for making you wade through Scribese.
@subsubsection(Meaning of @L[:unspecific] clarified)
@label(unspecific)
In a pathname, a value of @L[:unspecific] for a pathname component now
means that the component is meaningless in the pathname syntax of the
host. The following table shows the conditions under which a pathname
component can be @L[:unspecific].
@SymIndex[sym={:unspecific},key={unspecific}]
@Index[unspecific pathname component]
@begin(desplay)
@i(Component@\Conditions for @L[:unspecific])
Host@\Never
Device@\Always @L[:unspecific] for logical pathnames and pathnames for
Unix, Multics and the Lisp Machine file system.
Directory@\Never (for currently supported hosts)
Name@\Never
Type@\Sometimes @L[:unspecific] on ITS (see section @ref(ITS)). Always
@L[:unspecific] for UNIX and Multics file specs in which a name
component is specified with no period.
Version@\Always @L[:unspecific] for UNIX and Multics pathnames.
Sometimes @L[:unspecific] for ITS (see section @ref(ITS)).
@end(desplay)
Its use is now limited to these cases.
@subsubsection(Generic pathname changes)
@label(generic-pathnames)
Generic pathnames (as returned by the @L[:generic-pathname] message to
@L[fs:pathname]) now have @L[nil] as the type and version instead of
@L[:unspecific]. This was done as part of clarifying the meaning of
@L[:unspecific].
@subsubsection(ITS pathname merging)
@label(ITS)
Pathnames for ITS have been changed so that it is no longer possible to
have two ITS pathnames with the same meaning that differ in an ignored
component. @L[fs:*its-uninteresting-types*] still exists; it controls
which types are ignored in favor of retaining version numbers. The
following table summarizes the interaction of type and version
components for ITS pathnames.
@Index[ITS pathname merging]
@begin(format,longlines wrap, indent +3in)
@newtabs(+1.5in,+1.5in)
@i(Type@\Version@\Result)
supplied@\omitted@\type is retained, version is @L[:unspecific]
omitted@\supplied@\type is @L[:unspecific], version is retained
"interesting"@\supplied@\type is retained, version is @L[:unspecific]
"uninteresting"@\supplied@\type is @L[:unspecific], version is retained
@end(format)
∂06-Jun-83 1004 RPG Non-ballot
∂28-May-83 2017 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN Non-ballot
Received: from MIT-MC by SU-AI with TCP/SMTP; 28 May 83 20:17:21 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Sat 28-May-83 23:17:33-EDT
Date: Saturday, 28 May 1983, 23:09-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Non-ballot
To: Scott E. Fahlman <Fahlman%CMU-CS-C@SU-DSN>
Cc: dlw%scrc-tenex%mit-mc@SU-DSN, steele%CMU-CS-C@SU-DSN, rpg@su-ai
In-reply-to: The message of 28 May 83 22:34-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: Sat, 28 May 1983 22:34 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
There are a number of things that appeared in your initial list of
suggestions that, in my opinion, might want to be dropped instead of
appearing on a ballot to Common Lisp.
I'll omit any reference to the things that I already sent a message about
a few minutes ago (our messages crossed in the network).
Page 0: I agree that the language would be somewhat better off with
somewhat fewer mumble-p predicates, but I am really inclined to let
sleeping dogs lie on this issue. If you do want to pursue it, please
indicate which predicates should go.
In view of the quotation from the Federalist papers, I'll drop this.
Page 25: I can't believe that a package could ever be a raw hash-table
under the current package plan. I would always be a structure
containing one or more hash-tables, some lists, nicknames, and other
things. So this proposal is now obsolete, I think.
Okay. It was never an issue for our implementation anyway.
Page 37: In the manual, COERCE takes ARGUMENT, then RESULT-TYPE. Since
the other order is not clearly superior, let's let it be.
Okay.
Page 99: Do you still think that destructuring DEFMACRO is essential? I
really dislike mixing destructuring and &mumble in the same variable
list. I suppose that this can be made unambiguous, by saying that the &
words are only recognized at top-level in the list, and as soon as one
is seen, no more destructuring is allowed, but that's pretty ugly. What
if we had two flavors of defmacro, one with a lambda-like list and one
with destructuring? Or am I being too conservative here?
I think you're being too conservative. When an & keyword is seen,
everything to the right of that (within the same list) is in &-keyword
syntax and destructuring no longer applies. This is unambiguous. The
issue is that macros that take some special fields, usually enclosed in
parentheses, followed by "&BODY BODY" are ubiquitous and DEFMACRO
shouldn't force them to parse their arguments by hand (mainly because
that way you wouldn't have a self-documenting "lambda" list). This
feature of DEFMACRO has served us very well over the past few years.
Pages 103-105: If you want some sort of declaration (or proclamation)
form whose scope is local to a file, or sometimes is, or whatever,
please make a specific proposal.
Let's not do anything about this in Common Lisp right now. The issue is
perhaps really that (EVAL-WHEN (COMPILE) ...) doesn't necessarily really
mean "do the same thing as getting into a read-eval-print loop in the
middle of the compiler and evaling this." Some compile-time things are
undone at the end of compilation. But the lexical interpreter (i.e. more
context-sensitivity in the interpreter) makes this a much bigger can of
much squishier worms.
Page 164: "Should there be a mroe concise way..." Guy doesn't think so,
neither do I. Do you have a specific proposal to make?
Drop this, REDUCE is okay as it stands.
Page 166: "There should be a way..." Again, a proposal would be needed
here if you want to press the issue. I see no great need for an
additional function to do this.
[* 166: There should be a way to substitute for subsequences as well as for
single elements as SUBSTITUTE does. --KMP,Moon [not done]
{controversial and hairy}]
No time to do this now, but it's needed and should be in the second edition.
Is it really so hairy?
Page 167: I agree with Guy that NSUBSTITUTE should just parallel the
other similar forms.
Okay.
Page 192: Flush RESET-FILL-POINTER, add FILL-POINTER and SETF of it. I
would be inclined to let it be, but I don't care much either way. Is it
worth the effort?
I think this one is important. RESET-FILL-POINTER is an ugly wart. People
are going to say "well, if LENGTH is how you get the fill-pointer, then why
isn't (SETF (LENGTH ...)) how you set it?" Providing a FILL-POINTER function,
separate from LENGTH and separate from ARRAY-DIMENSION, clarifies the distinction
between the total length of a vector and the length of the valid part, which
is a distinction that you have to understand when changing fill-pointers.
Page 221: I thought we had voted to flush *IBASE* and just to use #O and
friends to get particular non-decimal constants in. Portable code
should not contain sections that use octal (or whatever) wholesale. If
you really want *IBASE* in Common Lisp, I will give in on this, but at
least we want a strong warning that this should not be used for whole
files or around large sections of code. We've got to break the dead
grip of octal someday.
Page 238: Presumably you have some use in mind for *PRINT-READABLY* ?
I'm curious what you think it is good for.
Both of these are for people who use the lisp reader and printer to
manipulate data files (not program source text files).
∂06-Jun-83 1004 RPG Left and right parentheses
∂28-May-83 2148 Guy.Steele@CMU-CS-A Left and right parentheses
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 28 May 83 21:48:05 PDT
Date: 29 May 1983 0047-EDT (Sunday)
From: Guy.Steele@CMU-CS-A
To: moon%scrc-tenex@MIT-MC, dlw%scrc-tenex@MIT-MC
Subject: Left and right parentheses
CC: rpg@SU-AI, Scott.Fahlman <FAHLMAN@CMU-CS-C>
I am willing to change "left" and "right" to "open" and "close",
but I am also *quite* sure that I don't have left and right backwards.
They may appear to be backwards because the algorithm is not obvious.
There is a bug in the algorithm, which is that incrementation of
dimension j should not output parentheses if j=n (but should still
cause incrementation of dimension j-1 if dimension j overflows).
Consider printing a 2-by-3-by-4 array containing the integers from 0 to 23.
First one prints "#3A" and 3 left parens:
#3A(((
Then elements are enumerated in row-major order until the last dimension
overflows, in this case elements with indices (0 0 0), (0 0 1), (0 0 2),
and (0 0 3):
#3A(((0 1 2 3
When the last dimension overflows, the next-to-last is incremented,
so print a right paren; there is no overflow; then print a left paren:
#3A(((0 1 2 3)(
Now continue to enumerate elements:
#3A(((0 1 2 3)(4 5 6 7
Now print a righ paren; no overflow; a left paren:
#3A(((0 1 2 3)(4 5 6 7)(
Now enumerate more:
#3A(((0 1 2 3)(4 5 6 7)(8 9 10 11
Now print a right paren; the penultimate dimension overflows, so
increment the dimension before that (the first one), which prints
another right paren; that one doesn't overflow; now print a left
paren; now print a left paren for the penultimate dimension:
#3A(((0 1 2 3)(4 5 6 7)(8 9 10 11))((
and so on. Actually, the condition j=n stated above is buggy:
should be j=n-1 to avoid outputting parens (I was in the wrong
origin). Also, I need to amend the algorithm to insert some spaces.
But you can see the general idea.
(I think the fix is: "then if dimension j has not overflowed, print a space,
but if it has overflowed and j>0, then increment dimension j-1".)
--Guy
∂06-Jun-83 1005 RPG More polished DEFSETF
∂29-May-83 1154 FAHLMAN@CMU-CS-C More polished DEFSETF
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 29 May 83 11:52:17 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 29 May 83 14:52:12 EDT
Date: Sun, 29 May 1983 14:52 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: steele@CMU-CS-C
Cc: rpg@su-ai, moon%scrc-tenex@mit-mc, dlw%scrc-tenex@mit-mc
Subject: More polished DEFSETF
Guy,
Dick Gabriel has polished up some of the wording on Moon's DEFSETF
writeup. The result is in <fahlman.clm>defsetf.mss. I have kept Moon's
original, renamed to defsetf.moon.
Looks like an improvement to me. Nothing substantive has been changed.
This could still use some more work, but it's good enough to ship as is
if we need to. Not too many novice users are going to have to wrestle
with this.
-- Scott
∂06-Jun-83 1005 RPG Package Chapter
∂29-May-83 1210 FAHLMAN@CMU-CS-C Package Chapter
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 29 May 83 12:10:43 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 29 May 83 15:10:44 EDT
Date: Sun, 29 May 1983 15:10 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: steele@CMU-CS-C
Cc: moon%scrc-tenex@mit-mc, dlw%scrc-tenex@mit-mc, rpg@su-ai,
cellio@CMU-CS-C
Subject: Package Chapter
Guy,
Monica has finished beating the Package Chapter into the proper Scribe
form, and has proofed it through Scribe. It should now be ready to drop
into the manual. In response to Benson's problem in understanding the
case rules, I have added a little not indicating that they are different
from the case rules for symbols. The result is on
<fahlman.clm>package.mss.
The Error chapter should be appearing next, and I already sent you a
pointer to RPG's polished version of DEFSETF.
My next task will be to go through the LASER.REPLY file, indicating
which of those "controversial" issues are now settled, which are
basically settled but require a confirmation, and which are still
unclear. Not too many of the latter.
Home before the leaves fall.
-- Scott
∂06-Jun-83 1005 RPG More polished DEFSETF
∂29-May-83 1312 @MIT-MC:MOON@SCRC-TENEX More polished DEFSETF
Received: from MIT-MC by SU-AI with TCP/SMTP; 29 May 83 13:11:50 PDT
Date: Sunday, 29 May 1983 16:15-EDT
From: MOON at SCRC-TENEX
To: Scott E. Fahlman <Fahlman at CMU-CS-C>
Cc: dlw%scrc-tenex at mit-mc, moon%scrc-tenex at mit-mc, rpg at su-ai,
steele at CMU-CS-C
Subject: More polished DEFSETF
In-reply-to: The message of Sun 29 May 1983 14:52 EDT from Scott E. Fahlman <Fahlman@CMU-CS-C>
RPG's changes are definite improvements. I made a couple more wording
improvements and fixed some editing spazzes. New version in prva:<slisp.scl>defsetf.mss
∂06-Jun-83 1006 RPG [Mailer: Message of 29 May 83 18:40:49 EDT]
∂29-May-83 1806 FAHLMAN@CMU-CS-C [Mailer: Message of 29 May 83 18:40:49 EDT]
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 29 May 83 18:06:21 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 29 May 83 21:06:25 EDT
Date: Sun, 29 May 1983 21:06 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: rpg@su-ai
Subject: [Mailer: Message of 29 May 83 18:40:49 EDT]
Date: 29 May 83 18:42:43 EDT
From: The Mailer Daemon <Mailer>
To: <FAHLMAN>
Re: Message of 29 May 83 18:40:49 EDT
Message failed for the following:
rpg@SU-AI: Timed out waiting for FTP reply
------------
Received: ID <FAHLMAN@CMU-CS-C>; 29 May 83 18:40:49 EDT
Date: Sun, 29 May 1983 18:40 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: steele@CMU-CS-C
Cc: moon%scrc-tenex@mit-mc, dlw%scrc-tenex@mit-mc, rpg@su-ai
Subject: Laser.reply
The file <fahlman.clm>laser.reply now contains comments by me indicating
which items I believe to be settled, which will be on the ballot (with
the recommendation I intend to make) and a few things on which I am
totally boggled. Almost everything is either settled or requires mere
confirmation via ballot (unless you folks disagree).
Note that I've got a handful of other issues to add to the ballot that
are not derived from Moon's file, but from other mail. The ballot will
go out sometime tomorrow. Replies will be expected within 3 days or so.
There will probably be a mini-ballot or two after the main one to pick
up stragglers (issus, that is, not people).
-- Scott
∂06-Jun-83 1006 RPG Laser.reply .reply .reply
∂29-May-83 2021 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN Laser.reply .reply .reply
Received: from MIT-MC by SU-AI with TCP/SMTP; 29 May 83 20:21:26 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Sun 29-May-83 23:24:23-EDT
Date: Sunday, 29 May 1983, 23:16-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Laser.reply .reply .reply
To: Fahlman%CMU-CS-C@SU-DSN
Cc: dlw%SCRC-TENEX%MIT-MC@SU-DSN, Steele%CMU-CS-C@SU-DSN, rpg@SU-AI
14: (table of minimum floating-point precision and range requirements) What
does an implementation on a machine that has no floating-point format that
satisfies one of these requirements do? For instance, the LM-2 has a maximum
floating-point precision of 31 bits. Double and Long modes require 50 bits.
Should the LM-2 provide "bogus" data types with those names, so that programs
that use them will run, inaccurately? Or should it omit those data types
completely? And what about the reader syntaxes?
Perhaps this is on the ballot via other mail, or fixed in the latest manual?
I didn't see anything about it in laser.reply (it got into laser.update later).
* 19: |P 4: [ENDP issue] Is the implementation allowed to cdr down into
an atom, or is the choice only between detecting the error or using an
ATOM test to terminate rather than an ENDP test?
<< Reworded for greater clarity. >>
Presumably resolved by that.
* 192g: flush reset-fill-pointer, add fill-pointer, and allow setf of fill-pointer. -- Moon
[not done]
{controversial}
<< OK, I'll put this on ballot with recommendation that we adopt it.
Just to clarify, FILL-POINTER of a vector is the same as LENGTH of the
vector, but only the former is legal in SETF. Right? >>
FILL-POINTER of a vector returns the same number as LENGTH returns, if
it returns. It "is an error" if the vector wasn't made with the
:FILL-POINTER keyword (thus it is an error for simple vectors).--Moon
<< OK, we need to clarify that CONSTANTP is true of Defconst symbols,
assorted atomic types, keywords, and lists whose CAR is QUOTE, right? >>
Right (given that by Defconst you meant DEFCONSTANT and that this includes
all the builtin ones like NIL, T, and PI).
* 222: (table 21-1) # is a non-terminating macro character in the Lisp
machine now. If Common Lisp is going to have them, # should be one. -- Moon [not done]
{controversial}
Probably needed for #: qualified names.
<< ??? I'm confused about this. Moon seems to be sure that this is
right, but I don't understand the implications. >>
Well, the only implications I know of are that you can use # in a symbol
as long as it isn't at the beginning, and you can use # in a package name
as long as it is neither at the beginning nor at the end. Usually you
shouldn't use it that way, of course. I'm assuming that the #: qualified
name is recognized by recognizing the : in whatever the normal way is, and
then noticing that the last character in the package name is a #.
* 233: (#=) It says the scope is "the outermost call to READ". Interaction
between recursive calls to READ is certainly mysterious. Probably there is
a kludge in BREAK to prevent the next READ from thinking it is called recursively.
I'd rather see a different function for macro-character functions that want
to read sub-expressions to call. This would unfortunately imply that
READ-DELIMITED-LIST is illegal for anything but a macro-character to call,
since it has to know which version of READ to use. If we don't add a separate
function, this mysteriosity should be carefully documented. -- Moon [not done]
{hard. I think a separate function will be needed. Alternatively,
how about an extra keyword :recursive to the input functions READ,
READ-PRESERVING-WHITESPACE, and READ-DELIMITED-LIST, which when
true specifies that a new ## scope is not to be made?}
<< Will put the :recursive keyword (and general conversion of READ
functions to keywords) on the ballot, vs. SUB-READ and
SUB-READ-DELIMITED-LIST. Recommend the former. >>
Of course you realize this means all those functions have to be changed
from optional arguments to keyword arguments. If that's unacceptable, make
new functions (only READ and READ-DELIMITED-LIST require two versions, since
the preserving-whitespace distinction isn't relevant on recursive calls,
and no other functions read "S-expression" syntax (as opposed to lines or
characters).
I just want to make sure the implications of changing the eof-error-p and
eof-value to keywords are thought out. Maybe it should be written up both
ways in the ballot so the voters can see it all laid out.
∂06-Jun-83 1007 RPG Laser.reply .reply .reply
∂29-May-83 2049 FAHLMAN@CMU-CS-C Laser.reply .reply .reply
Received: from SU-DSN by SU-AI with PUP; 29-May-83 20:49 PDT
Received: From CMU-CS-C by SU-DSN.ARPA; Sun May 29 20:51:31 1983
Received: ID <FAHLMAN@CMU-CS-C>; 29 May 83 23:49:12 EDT
Date: Sun, 29 May 1983 23:49 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: David A. Moon <Moon%SCRC-TENEX@MIT-MC>
Cc: dlw%SCRC-TENEX@MIT-MC, rpg%SU-AI@SU-DSN, Steele@CMU-CS-C,
fahlman@CMU-CS-C
Subject: Laser.reply .reply .reply
In-reply-to: Msg of 29 May 1983 23:16-EDT from David A. Moon <Moon%SCRC-TENEX at MIT-MC>
On 50-bit floating point:
Obvioulsy we cannot require any implementation to supply floating-point
formats of which its hardware is incapable. I think that the table of
minimum requirements for each format has now caused enough trouble that
we should seriously consider deleting it, or at least making it
"suggested minimum lengths".
On ENDP:
I would forbid implementations to use a NULL test if they do not signal
an error on CAR and CDR of an atom. To let the loop roll on through the
guts of an atom is clearly wrong, and efficiency be damned.
On FILL-POINTER:
Thanks for the clarification. I think I favor "signals an error" if you
do FILL-POINTER of an object that doesn't have one, not "is an error".
Is there a problem with this?
On CONSTANTP:
OK, CONSTANTP is true of DEFCONSTANT symbols, built-in constant symbols,
keywords, assorted atomic types, and lists whose CAR is QUOTE.
On # as a non-terminating macro character:
Well, the only implications I know of are that you can use # in a symbol
as long as it isn't at the beginning, and you can use # in a package name
as long as it is neither at the beginning nor at the end. Usually you
shouldn't use it that way, of course. I'm assuming that the #: qualified
name is recognized by recognizing the : in whatever the normal way is, and
then noticing that the last character in the package name is a #.
Mumble. This feels very wrong. Any other opinions out there?
On non-top-level READ, and friends:
I just want to make sure the implications of changing the eof-error-p and
eof-value to keywords are thought out. Maybe it should be written up both
ways in the ballot so the voters can see it all laid out.
The more I think about this, the better I like the idea of leaving the
current READ family alone and adding nearly-identical SUB-READ and
SUB-READ-DELIMTED-LIST for calls from macros. Cleaner. With keywords,
there's a small efficiency question (yes, resolvable by the compiler)
and also the issue of whether the stream argument becomes a keyword or
stays optional. I now want to propose SUB-mumbles.
∂06-Jun-83 1014 RPG Laser.reply .reply .reply
∂29-May-83 2121 MOON@SCRC-TENEX Laser.reply .reply .reply
Received: from SU-DSN by SU-AI with PUP; 29-May-83 21:21 PDT
Received: From MIT-MC by SU-DSN.ARPA; Sun May 29 21:23:30 1983
Date: Monday, 30 May 1983 00:22-EDT
From: MOON at SCRC-TENEX
To: Scott E. Fahlman <Fahlman at CMU-CS-C>
Cc: dlw at SCRC-TENEX, rpg%SU-AI at SU-DSN, Steele at CMU-CS-C
Subject: Laser.reply .reply .reply
In-reply-to: The message of Sun 29 May 1983 23:49 EDT from Scott E. Fahlman <Fahlman@CMU-CS-C>
Date: Sun, 29 May 1983 23:49 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
In-reply-to: Msg of 29 May 1983 23:16-EDT from David A. Moon <Moon%SCRC-TENEX at MIT-MC>
On 50-bit floating point:
Let's leave the table in but clarify that it's suggested, not required, and
that every implementation will have some numbers with those names, but they
may not conform to the table.
On ENDP:
I would forbid implementations to use a NULL test if they do not signal
an error on CAR and CDR of an atom. To let the loop roll on through the
guts of an atom is clearly wrong, and efficiency be damned.
Okay
On FILL-POINTER:
Thanks for the clarification. I think I favor "signals an error" if you
do FILL-POINTER of an object that doesn't have one, not "is an error".
Is there a problem with this?
No problem for us. We open-code it as (array-leader array 0), but that does
enough run-time checking to signal the error if it's not an array or doesn't
have a fill-pointer. If some implementations want to be able to open-code
fill-pointer and disable error checking, they can use an inline declaration.
On # as a non-terminating macro character:
Well, the only implications I know of are that you can use # in a symbol
as long as it isn't at the beginning, and you can use # in a package name
as long as it is neither at the beginning nor at the end. Usually you
shouldn't use it that way, of course. I'm assuming that the #: qualified
name is recognized by recognizing the : in whatever the normal way is, and
then noticing that the last character in the package name is a #.
Mumble. This feels very wrong. Any other opinions out there?
You really have a strong need to say (funcall#'foo'bar"quux") with no
spaces in between?
∂06-Jun-83 1018 RPG Mnemonic for PISERIUC
∂30-May-83 1252 Guy.Steele@CMU-CS-A Mnemonic for PISERIUC
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 30 May 83 12:51:55 PDT
Date: 30 May 1983 1547-EDT (Monday)
From: Guy.Steele@CMU-CS-A
To: Scott.Fahlman <FAHLMAN@CMU-CS-C>
Subject: Mnemonic for PISERIUC
CC: moon%scrc-tenex@MIT-MC, dlw%scrc-tenex@MIT-MC, rpg@SU-AI, dill@CMU-CS-C
To remember the order of Provide, IN-package, Shadow, EXport, Require,
USE-package, Import, Contents, I propose the mnemonic
"Put in seven extra random user interface commands."
(a) It works. I generated the list in the first two lines by using
the mnemonic.
(b) What it says is relevant to what you're doing: when you use it,
you are in fact trying to put in seven extra random user interface
commands.
--Guy
∂06-Jun-83 1027 RPG Mnemonic for PISERIUC
∂30-May-83 1252 Guy.Steele@CMU-CS-A Mnemonic for PISERIUC
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 30 May 83 12:51:55 PDT
Date: 30 May 1983 1547-EDT (Monday)
From: Guy.Steele@CMU-CS-A
To: Scott.Fahlman <FAHLMAN@CMU-CS-C>
Subject: Mnemonic for PISERIUC
CC: moon%scrc-tenex@MIT-MC, dlw%scrc-tenex@MIT-MC, rpg@SU-AI, dill@CMU-CS-C
To remember the order of Provide, IN-package, Shadow, EXport, Require,
USE-package, Import, Contents, I propose the mnemonic
"Put in seven extra random user interface commands."
(a) It works. I generated the list in the first two lines by using
the mnemonic.
(b) What it says is relevant to what you're doing: when you use it,
you are in fact trying to put in seven extra random user interface
commands.
--Guy
∂06-Jun-83 1028 RPG MAPHASH
∂30-May-83 1313 STEELE@CMU-CS-C MAPHASH
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 30 May 83 13:12:19 PDT
Received: ID <STEELE@CMU-CS-C>; 30 May 83 16:12:35 EDT
Date: 30 May 83 16:12:35 EDT
From: STEELE@CMU-CS-C
Subject: MAPHASH
To: fahlman@CMU-CS-C, rpg@SU-AI, moon%scrc-tenex@MIT-MC,
dlw%scrc-tenex@MIT-MC
I was all set to go for DOHASH, and then noticed that it would require
two iterator variables, unlike all the other DOxxx constructs.
So I propose to punt.
However, I would like to ask whether it would be an undue imposition
on the implementor to change the specification such that "adding
or deleting elements of the hash table while the MAPHASH is in progress
will cause unpredictable results, except that changing the value
of or deleting the element under consideration will have the
expected obviosu effect". (This is not the best prose.)
--Guy
-------
∂06-Jun-83 1029 RPG Mnemonic for PISERIUC
∂30-May-83 1349 FAHLMAN@CMU-CS-C Mnemonic for PISERIUC
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 30 May 83 13:49:08 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 30 May 83 16:48:36 EDT
Date: Mon, 30 May 1983 16:48 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Guy.Steele@CMU-CS-A
Cc: dill@CMU-CS-C, dlw%scrc-tenex@MIT-MC, moon%scrc-tenex@MIT-MC,
rpg@SU-AI
Subject: Mnemonic for PISERIUC
In-reply-to: Msg of 30 May 1983 1547-EDT () from Guy.Steele at CMU-CS-A
Good one. Hedrick will love it. The only problem is that the "extra"
tends to drop out for me. Do you want to add it as a footnote in the
manual or consign it to folklore?
-- Scott
∂06-Jun-83 1029 RPG MAPHASH
∂30-May-83 1352 FAHLMAN@CMU-CS-C MAPHASH
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 30 May 83 13:51:09 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 30 May 83 16:50:47 EDT
Date: Mon, 30 May 1983 16:50 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: STEELE@CMU-CS-C
Cc: dlw%scrc-tenex@MIT-MC, moon%scrc-tenex@MIT-MC, rpg@SU-AI
Subject: MAPHASH
In-reply-to: Msg of 30 May 83 16:12:35 EDT from STEELE
OK, I'm happy with this, I guess. As you say, not the best prose:
I'mnot sure what the "obviosu effect" is, since I speak neither Rumanian
nor Japanese.
-- Scott
∂06-Jun-83 1030 RPG Prose explaining floating point formats
∂30-May-83 1413 @MIT-MC:MOON@SCRC-TENEX Prose explaining floating point formats
Received: from MIT-MC by SU-AI with TCP/SMTP; 30 May 83 14:11:52 PDT
Date: Monday, 30 May 1983 16:53-EDT
From: MOON at SCRC-TENEX
To: STEELE at CMU-CS-C
Cc: dlw at SCRC-TENEX, fahlman at CMU-CS-C, rpg at SU-AI
Subject: Prose explaining floating point formats
In-reply-to: The message of 30 May 83 16:17:26 EDT from STEELE@CMU-CS-C
Good. Clarify that the maximum exponent size refers to the binary exponent
not the machine's actual exponent (for machines with octal or hexadecimal
floating point). The second case of two floating point formats has some
erroneous text copied from the first case, saying single differs from short.
∂06-Jun-83 1030 RPG Re: Mnemonic for PISERIUC
∂30-May-83 1504 Guy.Steele@CMU-CS-A Re: Mnemonic for PISERIUC
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 30 May 83 15:04:40 PDT
Date: 30 May 1983 1802-EDT (Monday)
From: Guy.Steele@CMU-CS-A
To: Scott E. Fahlman <Fahlman@CMU-CS-C>
Subject: Re: Mnemonic for PISERIUC
CC: dill@CMU-CS-C, dlw%scrc-tenex@MIT-MC, moon%scrc-tenex@MIT-MC, rpg@SU-AI
In-Reply-To: "Scott E. Fahlman's message of 30 May 83 15:48-EST"
I'm inclined to add it as a note to the manual. Maybe you would
be less inclined to forget the "extra" if you parsed it as
Put in seven extra-random user interface commands
! Also, the word "seven" in the phrase gives you some redundant
information that you can use as a check.
--Guy
∂06-Jun-83 1030 RPG Obviosu effect
∂30-May-83 1510 Guy.Steele@CMU-CS-A Obviosu effect
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 30 May 83 15:10:43 PDT
Date: 30 May 1983 1805-EDT (Monday)
From: Guy.Steele@CMU-CS-A
To: Scott E. Fahlman <Fahlman@CMU-CS-C>
Subject: Obviosu effect
CC: dlw%scrc-tenex@MIT-MC, moon%scrc-tenex@MIT-MC, rpg@SU-AI
In-Reply-To: "Scott E. Fahlman's message of 30 May 83 15:50-EST"
The Obviosu effect is the electromagnetic dual of the Hall effect.
It causes memory to be scrambled when you type on your keyboard,
for example. So if you try to delete a hash-table entry currently
given to the maphash function, it obviosuly clobbers your LISP.
--Quux
∂06-Jun-83 1031 RPG Mnemonic for PISERIUC
∂30-May-83 1535 FAHLMAN@CMU-CS-C Mnemonic for PISERIUC
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 30 May 83 15:35:23 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 30 May 83 18:35:16 EDT
Date: Mon, 30 May 1983 18:35 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Guy.Steele@CMU-CS-A
Cc: dill@CMU-CS-C, dlw%scrc-tenex@MIT-MC, moon%scrc-tenex@MIT-MC,
rpg@SU-AI
Subject: Mnemonic for PISERIUC
In-reply-to: Msg of 30 May 1983 1802-EDT () from Guy.Steele at CMU-CS-A
"extra" => "extremely"
∂06-Jun-83 1036 RPG Laser.reply .reply .reply
∂31-May-83 1207 DLW%SCRC-TENEX@MIT-MC Laser.reply .reply .reply
Received: from SU-DSN by SU-AI with PUP; 31-May-83 12:07 PDT
Received: From MIT-MC by SU-DSN.ARPA; Tue May 31 12:08:42 1983
Received: from SCRC-BORZOI by SCRC-TENEX with CHAOS; Tue 31-May-83 15:06:39-EDT
Date: Tuesday, 31 May 1983, 15:06-EDT
From: Daniel L. Weinreb <DLW%SCRC-TENEX@MIT-MC>
Subject: Laser.reply .reply .reply
To: Fahlman@CMU-CS-C
Cc: rpg%SU-AI@SU-DSN, Steele@CMU-CS-C, moon%SCRC-TENEX@MIT-MC
In-reply-to: The message of 29 May 83 23:49-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: Sun, 29 May 1983 23:49 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
On 50-bit floating point:
Obvioulsy we cannot require any implementation to supply floating-point
formats of which its hardware is incapable. I think that the table of
minimum requirements for each format has now caused enough trouble that
we should seriously consider deleting it, or at least making it
"suggested minimum lengths".
OK, I give up. If you want to make me happy in a minor point, add a
note saying "Please note that since these are only suggested lengths, if
your program depends on any particular accuracy, it is not portable." Or
something more euphemistic to that effect. At least it might be nice to
point out that if you write a program and say 5.0d3 or 5.0l3, you aren't
actually guaranteed any particular accuracy at all.
∂06-Jun-83 1036 RPG Laser.reply .reply .reply
∂31-May-83 1248 DLW%SCRC-TENEX@MIT-MC Laser.reply .reply .reply
Received: from SU-DSN by SU-AI with PUP; 31-May-83 12:48 PDT
Received: From MIT-MC by SU-DSN.ARPA; Tue May 31 12:43:55 1983
Received: from SCRC-BORZOI by SCRC-TENEX with CHAOS; Tue 31-May-83 15:41:06-EDT
Date: Tuesday, 31 May 1983, 15:40-EDT
From: Daniel L. Weinreb <DLW%SCRC-TENEX@MIT-MC>
Subject: Laser.reply .reply .reply
To: Fahlman@CMU-CS-C
Cc: rpg%SU-AI@SU-DSN, Steele@CMU-CS-C, moon%SCRC-TENEX@MIT-MC
In-reply-to: The message of 29 May 83 23:49-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
I take it that the "{okay by me}" things that were not further annotated
by you are accepted and will be changed in the manual.
It's OK with me if COERCE doesn't coerce characters to integers.
However, I strongly suggest putting in a clarification note to that
effect, i.e., say explicitly that it doesn't. Or maybe a Rationale note
saying that it doesn't because it wouldn't be clear what to do about the
char-code versus whole character, and telling you to use the
particularly function instead. This note is for the benefit of users
more than of implementors.
* 44: The rationale note: how so? If the compiler sees an arbitrary
form where it expects a keyword, well, how does it know that form
doesn't evaluate to a keyword symbol? Surely you aren't suggesting that
this be illegal? That would be no good at all. -- DLW [not done]
{In some situations type analysis will reveal that the arbitrary
form cannot produce a keyword. Simple example: a quoted expression
or number. For example, the compiler could catch (fill x y 0 5),
which should be (fill x y :start 0 :end 5).}
OK, the rationale note confused me. It would be better if it said "so
that a compiler can issue warnings about certain malformed calls". I
thought the implication of the note was that the compiler would ALWAYS
be able to detect such errors, at compile time!
* 103-105: The meaning and scope of global declarations in the Lisp
Machine is unclear. A top-level (declare (optimize ...)) probably wants
to apply only to the file in which it appears, whereas a top level
(declare (special ...)) has to side-effect the global environment and
persist after the file is loaded. -- DLW
{controversial}
<< Withdrawn until second edition. >>
It's not so much that I wanted to propose per-file declarations, as
mainly to clarify what (declare (optimize ...)) would mean at top level.
Right now, I truly am not sure what it means, and am not even completely
sure it is allowed. The only possibilities that are obvious to me are
(1) it's not legal, or (2) it's like a top-level special declaration, in
that there's some global mode saying what kind of optimization to use
if there's no overriding local declaration, and this sets the mode. I
don't care much how this is resolved, but I do think the manual should
make it clear, whatever the resolution is.
168: (BSG's note that maxprefix,maxsuffix,mismatch are redundant)
[done] [not done] [text clarified but there are still all three functions]
I still agree with BSG's note. They're redundant. We should do what
BSG recommended.
245: Does read-char echo on interactive streams? (Probably the answer
is "yes".) --DLW [not done]
Not to beat a dead horse, but please make sure that the manual gets changed
to clarify this, rather than left alone, even though we internally agree.
∂06-Jun-83 1036 RPG Prose explaining floating point formats
∂31-May-83 1332 @MIT-MC:DLW%SCRC-TENEX%MIT-MC@SU-DSN Prose explaining floating point formats
Received: from MIT-MC by SU-AI with TCP/SMTP; 31 May 83 13:32:08 PDT
Received: from SCRC-BORZOI by SCRC-TENEX with CHAOS; Tue 31-May-83 16:31:44-EDT
Date: Tuesday, 31 May 1983, 16:31-EDT
From: Daniel L. Weinreb <DLW%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Prose explaining floating point formats
To: STEELE%CMU-CS-C@SU-DSN, moon%SCRC-TENEX%MIT-MC@SU-DSN,
fahlman%CMU-CS-C@SU-DSN, rpg@SU-AI
In-reply-to: The message of 30 May 83 16:17-EDT from STEELE at CMU-CS-C
This is OK with me. (A real stuffy standards comittee probably wouldn't
be incredibly happy with the use of "appropriate", but I guess we can
assume that it's reasonably bovious to anyone...)
∂06-Jun-83 1037 RPG Left and right parentheses
∂31-May-83 1413 @MIT-MC:DLW%SCRC-TENEX%MIT-MC@SU-DSN Left and right parentheses
Received: from MIT-MC by SU-AI with TCP/SMTP; 31 May 83 14:12:35 PDT
Received: from SCRC-BORZOI by SCRC-TENEX with CHAOS; Tue 31-May-83 17:04:22-EDT
Date: Tuesday, 31 May 1983, 17:03-EDT
From: Daniel L. Weinreb <DLW%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Left and right parentheses
To: Guy.Steele%CMU-CS-A@SU-DSN
Cc: rpg@SU-AI, FAHLMAN%CMU-CS-C@SU-DSN, moon%SCRC-TENEX%MIT-MC@SU-DSN
In-reply-to: The message of 29 May 83 00:47-EDT from Guy.Steele at CMU-CS-A
OK, I see what the algorithm is. Speaking as one implementor who read
it and tried to use it as a guide, it's confusing. The basic problem
is that it seems to be saying "right paren, do something, left paren"
which looks backward. Of course, the printing isn't in the "do something",
so obviously I wasn't paying that much attention.
The phrasing, in particular the use of semicolons in the long sentence,
isn't too clear even in retrospect. It looks like you're saying that
you FIRST decide whether to print one right paren; then maybe increment
index j-1; then print a left paren. But actually there's a loop:
Now print a right paren; the penultimate dimension overflows, so
increment the dimension before that (the first one), which prints
another right paren;
Anyway, yeah, I didn't read it carefully enough. I guess it you clear
up the business about the loop and about the spaces, then it will no
longer look so simple that anyone will just pass over it the way I did...
∂06-Jun-83 1038 RPG MAPHASH
∂31-May-83 2105 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN MAPHASH
Received: from MIT-MC by SU-AI with TCP/SMTP; 31 May 83 21:01:37 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Wed 1-Jun-83 00:00:55-EDT
Date: Tuesday, 31 May 1983, 23:59-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: MAPHASH
To: STEELE%CMU-CS-C@SU-DSN
Cc: fahlman%CMU-CS-C@SU-DSN, rpg@SU-AI, DLW%SCRC-TENEX%MIT-MC@SU-DSN,
Moon%SCRC-TENEX%MIT-MC@SU-DSN
In-reply-to: The message of 30 May 83 16:12-EDT from STEELE at CMU-CS-C
Date: 30 May 83 16:12:35 EDT
From: STEELE@CMU-CS-C
I was all set to go for DOHASH, and then noticed that it would require
two iterator variables, unlike all the other DOxxx constructs.
So I propose to punt.
This seems like rather a silly reason to punt. Not that I am particularly
in favor of DOHASH. It might be a good idea to put parentheses around
the two variables, so that erroneous forms written by analogy with the other
DOxxx (where xxx isn't blank) constructs get detected.
However, I would like to ask whether it would be an undue imposition
on the implementor to change the specification such that "adding
or deleting elements of the hash table while the MAPHASH is in progress
will cause unpredictable results, except that changing the value
of or deleting the element under consideration will have the
expected obviosu effect". (This is not the best prose.)
This implies that the implementation of REMHASH must leave "deleted"
markers in the hash table rather than shifting other elements around. I
verified that our implementation does that; indeed most reasonable
hash-table implementations do. I note that our implementation of MAPHASH
has a bug having to do with hash tables' interaction with the garbage
collector: MAPHASH needs to check for the need to rehash before starting
the operation, otherwise the first REMHASH would rehash the table, moving
everything around and totally losing the state of MAPHASH. Our MAPHASH
does know to inhibit GC flipping during the operation, which means that
you can't rehash partway through except for the above bug. This also
means that if you stop the program in the middle of a MAPHASH, without
aborting it, your GC is turned off. But it will tell you so.
Some form of the above paragraph might make sense to put in an implementation
note.
∂06-Jun-83 1038 RPG Ballot
∂31-May-83 2205 FAHLMAN@CMU-CS-C Ballot
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 31 May 83 22:00:58 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 1 Jun 83 01:00:16 EDT
Date: Wed, 1 Jun 1983 01:00 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: rpg@su-ai
Cc: fahlman@CMU-CS-C, steele@CMU-CS-C
Subject: Ballot
On issue 7 you say "No. (See Steele's Comments.)"
So I did:
7: CATCH-ALL and UNWIND-ALL are currently the only means for trapping
any throw and being able to decide what it is. (UNWIND-PROTECT does
not have the latter property.) However, it may be best to omit these
until we have yet more experience with what we really want.
UNWIND-PROTECT does 90% of the job.
I take that as a somewhat unenthusiastic "yes" from Guy, so I'm a little
confused about your position.
I really want to flush these functions. I have to re-implement CATCH
and UNWIND-PROTECT for greater efficiency pretty soon, and I really
don't want to spend N days hacking on these turkeys unless someone comes
up with a good non-contrived example of where they are needed. Error
conditions are not such a place. None of our code in Spice Lisp has
ever used either of these. Do you have some use in mind, or are you just
arguing on aesthetic grounds. If the latter, can you be budged?
-- Scott
∂06-Jun-83 1038 RPG Laser.reply .reply .reply
∂31-May-83 2255 FAHLMAN@CMU-CS-C Laser.reply .reply .reply
Received: from SU-DSN by SU-AI with PUP; 31-May-83 22:53 PDT
Received: From CMU-CS-C by SU-DSN.ARPA; Tue May 31 22:49:35 1983
Received: ID <FAHLMAN@CMU-CS-C>; 1 Jun 83 01:47:00 EDT
Date: Wed, 1 Jun 1983 01:47 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Daniel L. Weinreb <DLW%SCRC-TENEX@MIT-MC>
Cc: moon%SCRC-TENEX@MIT-MC, rpg%SU-AI@SU-DSN, Steele@CMU-CS-C,
fahlman@CMU-CS-C
Subject: Laser.reply .reply .reply
In-reply-to: Msg of 31 May 1983 15:40-EDT from Daniel L. Weinreb <DLW%SCRC-TENEX at MIT-MC>
Welcome back. You missed a busy weekend.
I take it that the "{okay by me}" things that were not further annotated
by you are accepted and will be changed in the manual.
<< Yup. >>
It's OK with me if COERCE doesn't coerce characters to integers.
However, I strongly suggest putting in a clarification note to that
effect, i.e., say explicitly that it doesn't. Or maybe a Rationale note
saying that it doesn't because it wouldn't be clear what to do about the
char-code versus whole character, and telling you to use the
particularly function instead. This note is for the benefit of users
more than of implementors.
<< I assume Guy will do this. >>
OK, the rationale note confused me. It would be better if it said "so
that a compiler can issue warnings about certain malformed calls". I
thought the implication of the note was that the compiler would ALWAYS
be able to detect such errors, at compile time!
<< Another note for Guy to add. >>
It's not so much that I wanted to propose per-file declarations, as
mainly to clarify what (declare (optimize ...)) would mean at top level.
Right now, I truly am not sure what it means, and am not even completely
sure it is allowed. The only possibilities that are obvious to me are
(1) it's not legal, or (2) it's like a top-level special declaration, in
that there's some global mode saying what kind of optimization to use
if there's no overriding local declaration, and this sets the mode. I
don't care much how this is resolved, but I do think the manual should
make it clear, whatever the resolution is.
<< 2 is what I always assumed: it changes global state and hangs around
until somebody changes it. >>
I still agree with BSG's note. They're redundant. We should do what
BSG recommended.
<< On the ballot, and projected by our computer analysis to be a winner.
JONL voted against the 1+ part, but I can't figure out why. >>
245: Does read-char echo on interactive streams? (Probably the answer
is "yes".) --DLW [not done]
Not to beat a dead horse, but please make sure that the manual gets changed
to clarify this, rather than left alone, even though we internally agree.
<< Beating a dead horse is kind of therapeutic. You should try it
sometime. >>
∂06-Jun-83 1038 RPG MAPHASH
∂31-May-83 2328 FAHLMAN@CMU-CS-C MAPHASH
Received: from SU-DSN by SU-AI with PUP; 31-May-83 23:25 PDT
Received: From CMU-CS-C by SU-DSN.ARPA; Tue May 31 23:17:56 1983
Received: ID <FAHLMAN@CMU-CS-C>; 1 Jun 83 02:15:11 EDT
Date: Wed, 1 Jun 1983 02:15 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: David A. Moon <Moon%SCRC-TENEX@MIT-MC>
Cc: DLW%SCRC-TENEX@MIT-MC, rpg%SU-AI@SU-DSN, STEELE@CMU-CS-C,
fahlman@CMU-CS-C
Subject: MAPHASH
In-reply-to: Msg of 31 May 1983 23:59-EDT from David A. Moon <Moon%SCRC-TENEX at MIT-MC>
Thanks to Moon for pointing out the rather subtle GC bug in REMHASH.
That should indeed go in a note. As for DOHASH, it was my idea, nobody
else ever liked it much, and I have now repudiated it. So we don't ahve
to worry about the form of the dolist.
-- Scott
∂06-Jun-83 1040 RPG Top-level forms
∂02-Jun-83 1926 FAHLMAN@CMU-CS-C Top-level forms
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 2 Jun 83 19:26:35 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 2 Jun 83 22:26:02 EDT
Date: Thu, 2 Jun 1983 22:26 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: steele@CMU-CS-C
Cc: moon%scrc-tenex@mit-mc, dlw%scrc-tenex@mit-mc, rpg@su-ai,
fahlman@CMU-CS-C
Subject: Top-level forms
Guy,
There are still a couple of confusing issues surrounding the notion of
"top level forms" like DEFUN. You say that such forms are not illegal
when not at top-level, but that compilers may not process them right in
that case. Things inside a PROGN are virtually at top-level as far as
the compiler is concerned.
You also told me once that
(let ((x 0))
(defun foo (y) ...)
(defun bar (y) ...))
ought to work, and that this is the clearest way to create a lexical
closure of FOO and BAR over X and to get this closure compiled. You
need this sort of thing to do GENSYM and the like.
I think that in order to make these statements consistent, we have to do
one of two things:
1. Stipulate that the the compiler grovels through ALL random forms
found at top level, looking for functions to compile and setting up
lexical environments as it goes.
2. Make LET at top level be something like PROGN: the sub-forms are
treated as top-level, and they close over the LET variables. I assume
that the evaluation of the values for the LET variables would be done at
load time. This might want to work for LAMBDA too.
I favor the latter, of course, since I'll have to implement the thing.
This has to be ballotted, or at least explained to the masses. It's a
big change.
Or have I missed something critical? Maybe it's too long since I read
the RABBIT report.
-- Scott
∂06-Jun-83 1041 RPG Top-level forms
∂02-Jun-83 2155 FAHLMAN@CMU-CS-C Top-level forms
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 2 Jun 83 21:54:59 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 3 Jun 83 00:54:44 EDT
Date: Fri, 3 Jun 1983 00:54 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Guy.Steele@CMU-CS-A
Cc: RPG@su-ai, moon%scrc-tenex@mit-mc, dlw%scrc-tenex@mit-mc,
fahlman@CMU-CS-C
Subject: Top-level forms
In-reply-to: Msg of 3 Jun 1983 0020-EDT () from Guy.Steele at CMU-CS-A
Date: 3 June 1983 0020-EDT (Friday)
From: Guy.Steele at CMU-CS-A
To: Scott E. Fahlman <Fahlman>
Re: Top-level forms
Received: from CMU-CS-A by CMU-CS-C (with SMTP); 3 Jun 83 00:24:27 EDT
here is a simple trick that makes implementation easy in the compiler:
If you run across a random top-level form that you don't know
anything special about, call it (BAZ ...), and it should therefore be
evaluated at load time, compile it as if it were ((LAMBDA () (BAZ ...))).
That is, make a no-argument function out of it, compile that function,
and then immediately call it and throw it away. All the necessary
lexical processing will fall right out of that.
--Guy
OK, I knew I was missing something. So the proposal is that we actually
compile every random top-level form that is not otherwise special, and
that the lexical analysis is not nearly as bad as I thought. Then we
call this function at load-time and discard the result. That makes more
work for the compiler, but adds little complexity.
Can all of you implementor types live with that? If so, we need two
things added to the manual. One is an implementation note explaining
this trick, in case there's some other implementor out there who is as
thick as I am. The other is a list of all the top-level forms for which
this is NOT done. DEFanything, PROGN, PROCLAIM, ...?
This should considerably clarify the business in the manual about top
level forms.
-- Scott
I think S-1 can handle this with no trouble, especially since Steele
set up our compiler this way. Of course, the compiler doesn't work
the way he intended in all cases...
-rpg-
∂06-Jun-83 1041 RPG Top-level forms
∂02-Jun-83 2340 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN Top-level forms
Received: from MIT-MC by SU-AI with TCP/SMTP; 2 Jun 83 23:36:16 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Fri 3-Jun-83 02:37:12-EDT
Date: Friday, 3 June 1983, 02:35-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Top-level forms
To: Guy.Steele%CMU-CS-A@SU-DSN
Cc: Scott E. Fahlman <Fahlman%CMU-CS-C@SU-DSN>, RPG@su-ai,
moon%SCRC-TENEX%MIT-MC@SU-DSN, dlw%SCRC-TENEX%MIT-MC@SU-DSN
In-reply-to: The message of 3 Jun 83 00:54-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: Fri, 3 Jun 1983 00:54 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
Date: 3 June 1983 0020-EDT (Friday)
From: Guy.Steele at CMU-CS-A
here is a simple trick that makes implementation easy in the compiler:
If you run across a random top-level form that you don't know
anything special about, call it (BAZ ...), and it should therefore be
evaluated at load time, compile it as if it were ((LAMBDA () (BAZ ...))).
I don't like throw-away functions like this, probably for the wrong reason.
But perhaps you could tell me what problem this is supposed to solve.
If the compiler and the interpreter implement the same semantics, then
why do you need to compile top-level forms? Is it so that a function
definition deeply embedded inside that form somewhere will be seen and
compiled by the compiler? Unless there is some good reason for this I
doubt that we have much interest in implementing it. Of course, the
portable language doesn't actually provide a way to tell whether or not
something has been compiled, so an implementation can be in conformance
with the standard without actually compiling anything.
∂06-Jun-83 1042 RPG top-level forms
∂03-Jun-83 0018 @MIT-MC:MOON@SCRC-TENEX top-level forms
Received: from MIT-MC by SU-AI with TCP/SMTP; 3 Jun 83 00:18:12 PDT
Date: Friday, 3 June 1983 03:16-EDT
From: MOON at SCRC-TENEX
To: Steele at cmuc, Fahlman at cmuc
cc: rpg at sail, dlw at SCRC-TENEX, moon at SCRC-TENEX
Subject: top-level forms
In (let ((x 1))
(defun bar ()
... x ...))
what is the scope of the name bar?
In (defun foo (x)
(defun bar ()
... x ...))
what is the scope of the name bar? If these two answers are
different, what about
(dotimes (x 100)
(defun bar ()
... x ...))?
If none of the three answers is "global", then I like FLET/LABELS better
since they make the scope clear. If some of the three answers are "global",
then I'm unsure how to explain where the boundary lies.
∂06-Jun-83 1042 RPG
∂03-Jun-83 0414 @MIT-MC:RMS@MIT-OZ
Received: from MIT-MC by SU-AI with TCP/SMTP; 3 Jun 83 04:14:36 PDT
Date: Friday, 3 June 1983, 07:16-EDT
From: Richard M. Stallman <RMS at MIT-OZ>
To: Guy.steele at cmu
CC: rpg at sail, fateman at berkeley, gsb at ml, griss at utah
I recently went to California and discussed the question of
upward lexical closures with various people. They and I
are worried about the difficulty of telling whether the closure
will be passed upward, and the general slowdown of consing all closures
in case they do get used upward.
I suggest the idea of saying that FUNCTION makes a
closure that works only downward, and requiring the user to write
something else (such as (UPWARD #'(LAMBDA ...))) when he wants it
to be able to work upward.
I myself am able to implement the general FUNCTION in a way that
does not slow down the downward case for the sake of the upward case,
but the techniques I am using work only on Lisp machines.
I don't think the simplicity of making FUNCTION work in all cases
is worth screwing all implementations except the Lisp machine.
∂06-Jun-83 1043 RPG top-level forms
∂03-Jun-83 0632 FAHLMAN@CMU-CS-C top-level forms
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 3 Jun 83 06:32:27 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 3 Jun 83 09:31:51 EDT
Date: Fri, 3 Jun 1983 09:31 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: MOON%scrc-tenex@mit-mc
Cc: dlw%SCRC-TENEX@mit-mc, rpg@SU-AI, Steele@CMU-CS-C,
fahlman@CMU-CS-C
Subject: top-level forms
In-reply-to: Msg of 3 Jun 1983 03:16-EDT from MOON at SCRC-TENEX
Guy can correct this if I'm wrong, but I think that the manual is quite
clear on DEFUN setting the global function definition of the thing being
defined. So the answer to all of these would be "global", though the
second one provides a new definition for BAR every time FOO is called
and the third smashes the definition of BAR 100 times in quick
succession, leaving the last one in place.
Obvioulsy FLET and LABELS are more approprite if the purpose of the form
is to use BAR only within the lexical scope of the form that defines it.
The form I asked Guy about,
(let ((x 0))
(defun foo (y) ... x ...)
(defun bar (y) ... y ...))
seems more intuitive for writing two global definitions that share the
closure over X than if you were to replace the defuns with
(fset 'foo #'(lambda (y)...x ...))
-- Scott
∂06-Jun-83 1035 fateman%UCBKIM@Berkeley sqrt(-1)
Received: from UCB-VAX by SU-AI with TCP/SMTP; 6 Jun 83 10:32:19 PDT
Date: 6 Jun 83 10:23:57 PDT (Mon)
From: fateman%UCBKIM@Berkeley (Richard Fateman)
Subject: sqrt(-1)
Message-Id: <8306061723.6254@UCBKIM.ARPA>
Received: by UCBKIM.ARPA (3.340/3.5)
id AA06254; 6 Jun 83 10:23:57 PDT (Mon)
Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.341/3.31)
id AA01721; 6 Jun 83 10:18:21 PDT (Mon)
To: common-lisp@su-ai
Actually, I am tired of bringing this stuff up, but let me point out some
of the logical extensions. Let us say you are free to choose a different
form for the answer, depending on the value. That is what Alan Bawden says.
Well, how about having the exponential function choose a different float
format if the exponent would otherwise underflow or overflow? How about
having (pardon Maclisp syntax, which may in fact be wrong here)
(do ((i 10.0 (times 10 i)))nil (print i))
print forever, starting with
small floats (with small exponents), going to bigger floats, and then,
in the interests of preserving mathematical properties like (x*10)/10 = x,
going to bignum integers.
Do you really know the cost of not knowing that sqrt(float) is a float?
If someone expects a real and gets 0+1*i, does it come out as 0? In
which case is sqrt(-1) = 0 ?
Are you serious about people using CL for arithmetic? If so, I suggest
you find some people who are serious about using arithmetic, and have
thought about it more.
∂06-Jun-83 1147 @MIT-MC:MOON@SCRC-TENEX Revenge of the Ballot
Received: from MIT-MC by SU-AI with TCP/SMTP; 6 Jun 83 11:47:02 PDT
Date: Monday, 6 June 1983 14:46-EDT
From: MOON at SCRC-TENEX
to: common-lisp at su-ai
Subject: Revenge of the Ballot
In-reply-to: The message of Mon 6 Jun 1983 03:01 EDT from Scott E. Fahlman <Fahlman@CMU-CS-C>
B1. No mixed-type complexes. Yes.
B2. (SQRT -1.0) -> i, not an error. No vote.
I don't understand the implications of introducing a complex number
into a program that thought it was working entirely in the reals.
B3. MULTIPLE-VALUE-SETQ takes 0,2,4,... args. Yes.
I don't believe the claim that the format is completely different
from SETQ; it looks completely the same to me. Why else the
motivation to change the name to include "SETQ"?
B4. Cassels float proposals. Yes.
I'd like to see new names for FLOAT-{INTEGER-}SIGNIFICAND.
Also the sign should be returned as a third value and FLOAT-SIGN
should be flushed also, unless its two-argument form is deemed
important, in which case the manual should include a note about it.
B5. Recursive calls to READ supply a new optional arg. Yes, mostly.
I don't think the eof actions should be controlled by the top-level call
to READ; I think an eof in a recursive read is always an "eof in the
middle of an object" error. Note that this doesn't include an eof
that merely acts as a delimiter. For example:
<eof> use top-level eof control args
'<eof> eof in the middle of an object
'foo<eof> eof not seen until next read
I'd like to see a precise specification of what is controlled by the
recursive-read flag, since I suspect that it is ONLY the ## environment,
except for implementations (e.g. Maclisp) that optimize out some sort
of decoding of the stream argument.
B6. MERGE-PATHNAME-DEFAULTS -> MERGE-PATHNAMES Yes
MERGE-PATHNAME-DEFAULTS is okay provided only that its default-type
argument -not- be optional, or that it default to a function of the
defaults rather than to a constant (especially a constant that isn't
even a legal pathname component, as in the Laser manual!). But removing
it entirely from the Common language is okay, too.
B7. Pathname CONVENTION field. Yes.
It's not that I'm terribly opposed to this, but it just doesn't
seem to make any sense. How can the caller of PARSE-PATHNAME know
what syntax a pathname is written in, except by consulting the guy
who supplied the string? And how can the guy who supplied the
string say what syntax it is in, other than by putting something
in the string? The point is that the caller of PARSE-PATHNAME has
no business saying what syntax the string is in, doesn't care what
syntax it is, and in general cannot know what syntax it is.
Since the caller of PARSE-PATHNAME doesn't know what syntactic convention
to use, maybe his caller does; are you going to change a whole bunch
of functions, such as OPEN, DELETE-FILE, LOAD, COMPILE-FILE, DRIBBLE,
etc. to take a new CONVENTION argument? Then are you going to go one
level higher up and make the Read File command in your editor take
a CONVENTION argument, so it can parse the file name the user types
in? This is crazy!
The example of two file systems coexisting on the same host is bogus.
If you're going to use file name syntax to distinguish between them,
then what if they have the same syntax? All 3600s have two distinct
file systems that use the same syntax. And what about the user who
wants to be able to access files on both file systems, even if they
have different syntax? If the way you tell them apart is not in the
pathname, then how does the user say which pathnames are for which file
system? Obviously the answer is that the "host" field in a pathname
is not the name of a CPU, it is the name of a file system. If you
have two file systems resident on the same piece of iron, they have
different names. And conversely if you have one file system that
is attached to a multiprocessor, you don't say which of the processors
you want to access it through, you just say the name of the file system.
I also have little faith in the usefulness of accessing a Tops-20
file system with Unix-convention pathnames, or in general accessing any
host (file system) with a different convention than its native one;
either the different convention is trivially different (maybe Tops-20
with quotation marks around the directory and the name and version
delimited by spaces instead of dots), or it is semantically different
(no version numbers, as in Unix), in which case it won't work.
∂06-Jun-83 1230 RPG Top-level forms
∂03-Jun-83 2236 FAHLMAN@CMU-CS-C Top-level forms
Received: from SU-DSN by SU-AI with PUP; 03-Jun-83 22:35 PDT
Received: From CMU-CS-C by SU-DSN.ARPA; Fri Jun 3 22:38:04 1983
Received: ID <FAHLMAN@CMU-CS-C>; 4 Jun 83 01:34:39 EDT
Date: Sat, 4 Jun 1983 01:34 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: David A. Moon <Moon%SCRC-TENEX@MIT-MC>
Cc: dlw%SCRC-TENEX@MIT-MC, Guy.Steele@CMU-CS-A, RPG%su-ai@SU-DSN
Subject: Top-level forms
In-reply-to: Msg of 3 Jun 1983 02:35-EDT from David A. Moon <Moon%SCRC-TENEX at MIT-MC>
I tried to answer this earlier today, and then CMUC crashed for six
hours. Sigh!
Yes, the suggestion by Guy provides a way to compile functions embedded
at other than the top level in the proper lexical context without having
to add a lot of extra compiler hair to keep track of the lexical context
set up by surrounding LET forms and such.
I agree that no implementation should be required to do this, but I
think it is important for high-quality implementations to do so. The
reason this is now important is that any function that wants to close
over some lexical environment will now be non-top-level -- it will be
enclosed in a LET or LAMBDA or something like that. This is not so
important for GENSYM clones, but some of these functions might be
substantial and time-critical.
A beneficial side-effect is that certain top-level initialization forms
will now run much faster, especially in implementations like ours (and
yours) where interpreted code is much slower than compiled code. An
unfortunate side-effect is that now the compiler wastes some time
compiling trivial init forms.
-- Scott
∂06-Jun-83 1230 RPG Top-level forms
∂03-Jun-83 2253 Moon%SCRC-TENEX@MIT-MC Top-level forms
Received: from SU-DSN by SU-AI with PUP; 03-Jun-83 22:53 PDT
Received: From MIT-MC by SU-DSN.ARPA; Fri Jun 3 22:55:38 1983
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Sat 4-Jun-83 01:51:35-EDT
Date: Saturday, 4 June 1983, 01:50-EDT
From: David A. Moon <Moon%SCRC-TENEX@MIT-MC>
Subject: Top-level forms
To: Scott E. Fahlman <Fahlman@CMU-CS-C>
Cc: dlw%SCRC-TENEX@MIT-MC, Guy.Steele@CMU-CS-A, RPG%su-ai@SU-DSN
In-reply-to: The message of 4 Jun 83 01:34-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: Sat, 4 Jun 1983 01:34 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
A beneficial side-effect is that certain top-level initialization forms
will now run much faster, especially in implementations like ours (and
yours) where interpreted code is much slower than compiled code. An
unfortunate side-effect is that...
.....we have to make compiled functions garbage collectable or else live with
a lot of functions that will never be called again not only taking up address
space, but sitting in between the real functions making them less local in
virtual memory.
I think we already long ago figured out that such top-level initialization
forms whose speed matters should be made into call-once functions and a
call to the function written write below its definition, so we don't need
the compiler to do that for us.
Perhaps the compiler can MAPFORMS through a top-level form looking for DEFUNs,
and if it doesn't find any leave it alone.
∂06-Jun-83 1230 RPG
∂04-Jun-83 1534 FAHLMAN@CMU-CS-C
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 4 Jun 83 15:34:28 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 4 Jun 83 18:34:11 EDT
Date: Sat, 4 Jun 1983 18:34 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Dick Gabriel <RPG@SU-AI>
Cc: ROD@SU-AI
In-reply-to: Msg of 03 Jun 83 1126 PDT from Dick Gabriel <RPG at SU-AI>
A15. Ok. I cannot parse `the equating of valid array dimensions with fixnums.'
Does this mean he wants them to be complex numbers? Reals? Transcendentals?
I though Moon was the one who said that it's about time people stopped
designing languages based on implementability? I guess that's only
true for features his machine can implement well. I want FFT in CL!!!
All the matrix operations too!
The proposal is that we no longer specify in the manual that the maximum
array dimension must be identical to the largest fixnum. It must of
course be an integer, but an implementation might have some good reason
to make it larger or smaller.
As for FFT and matrix ops, make a proposal...
Scott. I'm sorry for being so sarcastic, but every now and then I get the
urge to rename this Lisp Moon-lisp or Symbolics-Lisp. I suppose, though,
that it is in Symbolics's best interest to make CL just complex enough
that a 3600 can run it and no lesser machine can. If they can also flush
stock hardware in the bargain, so much the better. My fantasy is to make
it just complex enough to rule out anything less than an S-1. Then we
could start over, and use good taste *and* a modest appetite.
Well, at the risk of convincing you even further that I'm in Moon's
pocket, I think I must defend him. Moon has had a lot of influence
lately, perhaps because I tend to find his arguments convincing and
because my taste seems to coincide with his to a considerable extent.
On the issue of Common Lisp complexity, I've tried to make sure that
nothing goes in that we can't implement pretty well on a Vax. None of
the recent stuff messes that up, though there were some major decisions
early on that hurt stock hardware: optional args, multiple value,
generic sequences, the vector/array business, and so on.
On the issue of total size of the language, back when we were just Spice
Lisp, we were going to start with a nice little language and let it grow
as all Lisps have into something with all the features the users might
want. Symbolics has a mature implementation with all that stuff in
already, most of it in good shape and a few things badly deformed. We
could have taken the route of putting only the bare essentials into
Common Lisp, with the rest as optional packages, but the total size of a
usable configuration would be about the same. By standardizing as much
of this optional stuff as we can agree on, we make code and users MUCH
more portable -- otherwise, every big system would have to come bundled
with its own particular set of macros, sequence operators, output
formatters, and so on. So, while I find the total size of the language
somewhat obnoxious, I think that we have taken the right path here. The
only problem is that Common Lisp will never run on a machine with less
than a couple of megabytes of virtual memory; in couple of years, even
the pocket computers will have that.
A useful thing for the production of turnkey systems would be a program
to build partial Common Lisp systems. You write your program in Common
Lisp on a big machine, maybe being careful to avoid using features you
don't really need. Then this program assembles a minimal program load
consisting of your system and any modules from Common Lisp that it
touches. Most things would leave behind hyperbolic arctan and 9/10 of
FORMAT. I think that this would be a bigger win than trying to come up
with a standard subset. Once we have some real code in hand, it will be
easy to anylyze it and see if I am right.
-- Scott
∂06-Jun-83 1231 RPG [Mailer: Message of 5 Jun 83 15:33:40 EDT]
∂05-Jun-83 1317 FAHLMAN@CMU-CS-C [Mailer: Message of 5 Jun 83 15:33:40 EDT]
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 5 Jun 83 13:16:47 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 5 Jun 83 16:17:31 EDT
Date: Sun, 5 Jun 1983 16:17 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: rpg@su-ai
Subject: [Mailer: Message of 5 Jun 83 15:33:40 EDT]
Date: 5 Jun 83 16:14:38 EDT
From: The Mailer Daemon <Mailer>
To: <FAHLMAN>
Re: Message of 5 Jun 83 15:33:40 EDT
Message failed for the following:
RPG@SU-AI: Timed out waiting for FTP reply
------------
Received: ID <FAHLMAN@CMU-CS-C>; 5 Jun 83 15:33:40 EDT
Date: Sun, 5 Jun 1983 15:33 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Dick Gabriel <RPG@SU-AI>
Cc: steele@CMU-CS-C, fahlman@CMU-CS-C
Subject: Number of arguments
In-reply-to: Msg of 05 Jun 83 1146 PDT from Dick Gabriel <RPG at SU-AI>
Your example makes it clear to me that it is desirable for an
implementation to support 1000 named args. But do you really want to
propose this as a universal limit? What if a stcok-hardware
implementation can run faster by a factor of 2 or 3 if it sets this
limit at 50 that if it goes to 1000, because in the latter case it has
to do complex stack-shuffling or soemthing? Should we force such an
implementation to go for the big limit? Should we penalize all Lisp
code because one program out there wants 1000 named args? We've
confronted this issue for small arg counts like 5 or 7, and decided to
require more, but I'm not sure that requiring ALL Common Lisp
implementations to go for 1000 args is the right move. Is this really
what you think we should do?
-- Scott
I guess I'm not sure how going to 1000 from 50 could cause a slowdown for
the common cases, and I can't really see where there would be a major
slowdown (say 15%) for large cases. I presume that the major slowdown
occurs when you increase the number of named arguments beyond the number
of free registers, in which case you use the stack. PSL is the only
implementation I know that currently uses registers instead of a stack for
argument-passing. I assume, and I could be wrong, that all the machines we
are talking about for Common Lisp can address all of its address space,
including anywhere on the stack. I also presume that the compiler can
determine how many named arguments a function has and can supply
addressing modes, or scratch memory and shuffling, for those beyond 50.
So, if I use at most 50, the compiler can guarantee the fast case; if I
use more, then maybe I will lose performance by shuffling (if there really
is such a machine). I admit that I'll lose compiler performance.
In short, can you tell me why this isn't a compiler problem and not
a performance problem for the most common cases?
-rpg-
∂06-Jun-83 1231 RPG Arguments about arguments
∂05-Jun-83 1441 FAHLMAN@CMU-CS-C Arguments about arguments
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 5 Jun 83 14:41:26 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 5 Jun 83 17:42:07 EDT
Date: Sun, 5 Jun 1983 17:42 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Dick Gabriel <RPG@SU-AI>
Cc: steele@CMU-CS-C
Subject: Arguments about arguments
In-reply-to: Msg of 05 Jun 83 1334 PDT from Dick Gabriel <RPG at SU-AI>
OK, having the 1000-arg case around does not necessarily slow down the
50-arg case if you're willing to use separate mechanisms for each, and
you can even get around the runtime cost of deciding which case you
have, since the number of args is known at compile time. The simplest
case is just the length of field required for various argument offsets,
for which you must now either go beyond one byte (extra fetch time) or
provide an escape to get extra bytes. Machines that don't have good
virtual memory systems would have additional problems, worrying about
whether a whole call frame will fit into a segment and shuffling if not,
but maybe we don't care about those.
But even if we avoid slowing down an implementation by the clever use of
escapes to handle large numbers of args, there is still a cost: we are
now asking implementors to spend some of their hacking time and memory
space (maybe microcode space) to implement these additional mechanisms
that may or may not ever be used. I can imagine a lot of implementors
deciding to deviate from the standard here, or to implement this part
"later".
I guess I don't really have a consistent philosophy about all this, just
a gut reaction. You have persuaded me that my implementations ought to
handle as many args as possible, one way or another, but it seems to me
that the "minimum maxima" of the standard ought to provide an adequate
umbrella for the sorts of things whose portability are essential:
portable flavor packages, matrix arithmetic, etc. Anything that is more
than a couple of standard deviations out from current programming
practice should probably have to look around at the environment to see
if it can run. (The most named variables that I have ever seen in a
function is about 10, and 99% of Lisp functions are under 5.)
Whatever you freind is doing, it is a very different game from using
arguments in the normal sense. I can't imagine that he will be happy
with 1000 args for long. He will be back wanting 64K in a year, and 1M
a year after that. Maybe the right move is to make him pass these
things in an array or something, instead of making every Common Lisp
handle 1K or 1M arguments.
-- Scott
∂06-Jun-83 1232 RPG Revenge of the Ballot
∂06-Jun-83 0111 FAHLMAN@CMU-CS-C Revenge of the Ballot
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 6 Jun 83 01:10:34 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 6 Jun 83 03:01:56 EDT
Date: Mon, 6 Jun 1983 03:01 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: common-lisp@su-ai
Cc: fahlman@CMU-CS-C
Subject: Revenge of the Ballot
Ballot B:
A few loose ends. With luck, this will be the final ballot before the
manual is finalized for the first edition. There may be a couple of
messages on single issues that pop up during final cleanup of the
manual, but this should be the last multi-issue submission.
Please reply by dawn, Tuesday morning. I plan to collate the answers
later in the day on Tuesday.
---------------------------------------------------------------------------
B1. Proposed that we require both halves of a complex number to be of
the same type, either both rationals or both floats of the same type.
The COMPLEX function will accept numeric arguments of mixed type, but it
will do floating-point contagion of the usual sort (floats dominate
rationals, floats of greater precision dominate those of lesser) before
returning the complex number.
[ I am not really qualified to have an opinion on this. It would make
the system easier to implement, easier to understand, and it would get
rid of an ugly exception or two. On some hardware (the S-1, for
example) homogeneous-type complexes can be handled by the hardware,
while mixed types are more awkward. Therefore, if none of the
mathematicians in the audience has a good reason NOT to do this, it
looks like a good move to me. ]
Yes.
---------------------------------------------------------------------------
B2. Proposed that we adopt Alan Bawden's suggestion that we return a
complex number from functions like (sqrt -1), where we would otherwise
have to signal an error. If not this, please indicate what you think we
should do.
[ Same comment as above. If we're going to have complexes (and we are),
it seems wrong for (sqrt -1) not to return one. ]
I don't know what is right. I think, though, that there ought to be a way
to declare that you want to be in the real domain, so that the behavior
of (sqrt -1) would change depending on the domain. This declaration
would be of use exspecially if you are writing generic all the time.
---------------------------------------------------------------------------
B3. Now that we have decided to change from MULTIPLE-VALUE to
MULTIPLE-VALUE-SETQ, Moon says that we must have this form take
pairs of arguments like SETQ and PSETQ. Yes or no?
[ I say no. The format is completely different since there is a list of
N variables and one value-producing form. I don't think anyone will
assume that it must take pairs of variables (variable-lists, really) and
values as SETQ does. To add this would be MORE confusing, not less. ]
No.
---------------------------------------------------------------------------
B4. Proposals by Robert Cassels to change FLOAT-SIGNIFICAND and friends.
[ These all look like good changes to me. There were also a couple fo
suggested clarifications to the manual that Guy can deal with. Vote on
each part separately if you need to. ]
B4a. Proposal: Remove FLOAT-EXPONENT and FLOAT-INTEGER-EXPONENT, and
return those numbers as the second values from FLOAT-SIGNIFICAND and
FLOAT-INTEGER-SIGNIFICAND.
This would serve to make these functions more similar to the division
functions, and emphasize the close relationship between the values. It
also leads to slightly improved efficiency of implementation,
particularly on systems with unnormalized (or denormalized) numbers, and
those with "non-numeric" floating-point values [IEEE floating-point,
anyone?] which must be checked. (I'm assuming that when one value is
wanted, the other is almost always wanted also.)
B4b: Proposal: Add new functions FLOAT-DIGITS and FLOAT-PRECISION.
(FLOAT-DIGITS float) would return the number of (FLOAT-RADIX
float) digits used in the representation of a floating-point number.
(Including the "hidden bit", if any.) For most implementations, this is
really a property of the type of float.
(FLOAT-PRECISION float) would return the number of significant
(float-radix float) digits present in float.
Implementation: For implementations using only normalized numbers, these
functions would be identical. (- (FLOAT-DIGITS float) (FLOAT-PRECISION
float)) would reflect the degree of denormalization of float.
These functions are needed to simplify the movement of floating-point
numbers from one implementation to another. They are also needed to
convert numbers from one base to another in a way which reflects the
precision (doesn't print bogus digits). FLOAT-DIGITS could be
computed for most implementations by (- (FLOAT-EXPONENT 1.0)
(FLOAT-EXPONENT SINGLE-FLOAT-EPSILON)) or something like that. But
making it a function seems cleaner than some sort of typecase.
B4c. Proposal: Require the result of FLOAT-INTEGER-SIGNIFICAND to
reflect the precision of the floating-point number.
Currently, FLOAT-INTEGER-SIGNIFICAND is only required to satisfy the
identity relating it to FLOAT-INTEGER-EXPONENT. That allows the result
to be scaled by various powers of the radix, so long as the exponent is
adjusted appropriately. So if @i[b] is (FLOAT-RADIX float) and @i[p] is
(FLOAT-PRECISION float), the result of (FLOAT-INTEGER-SIGNIFICAND float)
for non-zero float should be between (EXPT b p) (exclusive) and (EXPT b
(1- p)) (inclusive).
Ok.
---------------------------------------------------------------------------
B5. We've stil got to settle the business of top-level vs. recursive
calls to READ and friends. Having considered all of the mail that has
flown by on this, I re-propose the following:
All of the functions that now take EOF-ERRORP and EOF-VALUE arguments
(except for READ-BYTE and READ-BINARY-OBJECT) will take an additional
optional arg after EOF-VALUE. This arg, RECURSIVE-P, should be NIL if
the function is called at the top level in a read, T otherwise. It
defaults to NIL. If this is non-null, the eof actions are controlled
not by the funciton's own controls, but by the top-level call. Also,
only top-level calls rebind the ## environment, etc.
I was thrown for a bit of a loop by Eric Benson's suggestion that
read-macro functions have to know whether they are at top-level so that
they will know whether their own calls to read are recursive or
top-level. That seemed to require some heavy-duty changes until I
realized that a macro-character function is always called within a READ,
so it always wants to the calls it makes to be recursive, unless perhaps
it is initiating some sort of top-level dialogue with the user instead
of gobbling down more of the stream in which the macro character was
read. Of course, this assumes that you don't call random
character-macro functions directly, but that they only get called by the
reader.
[ I think this does it. Propose alternatives if you want to, but also
please indicate whether you can live with this. ]
Ok, I guess.
---------------------------------------------------------------------------
B6. Rename MERGE-PATHNAME-DEFAULTS to MERGE-PATHNAMES and eliminate the
default-type argument. (This is obtained from the defaults.)
[ Suggested by the folks at Symbolics who have experience with these
things. They claim that users get terribly confused if the default type
present in the DEFAULTS argument is not used. Sounds good to me.]
Ok
---------------------------------------------------------------------------
B7. Propose that we add a new slot, CONVENTION, to the pathname
structure, and an optional CONVENTION argument to the PATHNAME and
TRUENAME functions. This convention is used in parsing the argument, if
it is a string, and is recorded in the resulting pathname structure so
that the pathname can be turned back into a namestring in the same
format. CONVENTION is a symbol, not a string; the collection of
meaningful convention symbols is implementation-dependent.
PARSE-NAMESTRING, which already has a convention argument, would be
brought into conformity with this.
The rule should be that the convention, if it is supplied, is used to
guide the parsing, and an error is signalled if the string is not legal
in this convention. If the convention is not supplied, the system will
examine the string and attempt to deduce the convention in some grossly
implementation-specific or site-specific way, perhaps by recognizing the
host name and looking up that host's convention in a table. We should
not specify anything about how this is done; in particular, do not
specify that the host is delimited by "::".
The point is that the current proposal (a simplified subset of the
existing Lispm pathname facility) muddles together the notion of HOST
(the machine or network node where the file resides) and CONVENTION
(what file-naming convention is used in this file name). A host might
be "CMUC"; its convention might be "TOPS-20". A convention runs on many
hosts, and it is quite possible that some hosts will provide more than
one convention. (Our 3600's may one day have a band full of
Symbolics-format files and a band full of Spice-format files, coexisting
happily; there are other examples around.) In any event, code can be
more portable if it can deal with something as a Tops-20 filename than
as "whatever CMUC is". Many places in the pathname section refer to
some feature as "host-dependent", when in fact it depends on the
convention.
[ I'm in favor. ]
Ok.
∂06-Jun-83 1316 ALAN@MIT-MC sqrt(-1)
Received: from MIT-MC by SU-AI with TCP/SMTP; 6 Jun 83 13:16:00 PDT
Date: 6 June 1983 15:02 EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: sqrt(-1)
To: fateman @ UCBKIM
cc: Common-Lisp @ SU-AI
Date: 6 Jun 83 10:23:57 PDT (Mon)
From: fateman%UCBKIM at Berkeley (Richard Fateman)
Let us say you are free to choose a different form for the answer,
depending on the value. That is what Alan Bawden says.
I did not propose anything different from what is already done with
bignums. Certain potential bignums are illegal because they can be
represented with fixnums. Similarly certain potential rationals are to be
illegal because they are not in lowest terms, the denominator is negative,
or they can be represented with fixnums or bignums. Finally certain
potential Gaussian rationals are to be disallowed because they can be
represented using rationals, bignums or fixnums.
Well, how about having the exponential function choose a different float
format if the exponent would otherwise underflow or overflow?
I proposed nothing resembling this. Neither did anybody else as far as I
can see. If someone has an argument in favor of it, they should speak up,
otherwise I suggest we dismiss the idea as a strawman you devised to give
yourself something to argue against.
Do you really know the cost of not knowing that sqrt(float) is a float?
Is add1(fixnum) a fixnum? Sqrt(float) is a float for positive arguments
and is a (complex float) for negative arguments. Or it will be if we so
vote.
If someone expects a real and gets 0+1*i, does it come out as 0? In
which case is sqrt(-1) = 0 ?
Are you serious? This is Lisp, what does it mean to "expect" a real?
(SQRT -1) => #C(0 1), today and tomorrow.
Are you serious about people using CL for arithmetic? If so, I suggest
you find some people who are serious about using arithmetic, and have
thought about it more.
After reading your message I'm fairly certain that we have though about
these issues more than you have. I have been carefully reading every word
you send on this subject and so far your objections have consisted entirely
of misunderstandings and bombast.
∂06-Jun-83 1317 fateman%UCBKIM@Berkeley Re: sqrt(-1)
Received: from UCB-VAX by SU-AI with TCP/SMTP; 6 Jun 83 13:17:26 PDT
Date: 6 Jun 83 13:18:47 PDT (Mon)
From: fateman%UCBKIM@Berkeley (Richard Fateman)
Subject: Re: sqrt(-1)
Message-Id: <8306062018.8926@UCBKIM.ARPA>
Received: by UCBKIM.ARPA (3.340/3.5)
id AA08926; 6 Jun 83 13:18:47 PDT (Mon)
Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.341/3.31)
id AA04089; 6 Jun 83 13:13:10 PDT (Mon)
To: ALAN@MIT-MC
Cc: common-lisp@su-ai
(1+ fixnum) IS a fixnum in Franz. It is fairly important to our compiler
that it be. It could be important that sqrt returns a real for similar
reasons. You can record my vote as saying that IF sqrt returns complex
sometimes, then there should be another say, sqrt-real. If you want to
treat arithmetic as 2nd class, a tradition in Lisp, fine.
∂06-Jun-83 1534 HEDRICK@RUTGERS.ARPA Re: Revenge of the Ballot
Received: from RUTGERS by SU-AI with TCP/SMTP; 6 Jun 83 15:22:42 PDT
Date: 6 Jun 83 18:24:32 EDT
From: Dir LCSR Comp Facility <HEDRICK@RUTGERS.ARPA>
Subject: Re: Revenge of the Ballot
To: Fahlman@CMU-CS-C.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: Message from "Scott E. Fahlman <Fahlman@CMU-CS-C>" of 6 Jun 83 03:01:00 EDT
I am going to give one of three answers: Yes, No, OK, and abstain. OK
means that it looks good to me, but I don't know enough for that fact to be
significant. Abstain means I don't know enough to be able to tell whether
it is even superficially plausible.
B1. OK. One possible disadvantage is that floating-point contagion
is not guaranteed to work. That is, floating point has an upper
bound, whereas bignum's don't. What would you do with
(COMPLEX 1E-5 ZILLION), where ZILLION is a very big bignum?
B2. OK, although I have a sneaking suspicion that it might be useful to
have either a REAL-SQRT function or the ability to say (SETQ
*NO-COMPLEX-NUMBERS-PLEASE* T). You should realize that I also believe
(CDR NIL) should be an error, and for the same reason. So for
consistency, you should probably ignore this.
B3. No, don't take pairs of arguments.
B4a. abstain
B4b. Yes
B4c. abstain
B5. abstain. My first reaction is negative. I somehow implemented a
complete Lisp, including read macros, without needing to do this. I am
always able to keep track of what is going on without requiring an
explicit argument from the user. I can only conclude from the
discussion that there must be something odd about Common Lisp such that
this can't be done. I can't imagine what it would be, but if the Spice
folks are convinced it is so, I will defer to them. (After all, I am
stealing most of their implementation, so it would not be very gracious
of me to refuse them the tools they feel they need to do it.)
B6. OK
B7. Yes, but can't we do a better job of defining what conventions are?.
Instead of the magic identifier TOPS-20, maybe
"HOST::DEVICE:<DIRECTORY>NAME.TYPE.VERSION", or maybe this could be the
DEFINITION property of TOPS-20. This assumes that no system will use
letters as delimiters. If this is a problem, I can come up with a more
general metasyntax.
-------
∂06-Jun-83 1703 GSB@MIT-ML Revenge of the Ballot
Received: from MIT-ML by SU-AI with TCP/SMTP; 6 Jun 83 17:02:52 PDT
Date: 6 June 1983 20:04 EDT
From: Glenn S. Burke <GSB @ MIT-ML>
Subject: Revenge of the Ballot
To: Fahlman @ CMU-CS-C
cc: common-lisp @ SU-AI
B1, B2, B4, B5, and B6, are acceptable to me. (I do not claim
particular mathematical competence however. And, B4a brings up some
of the issues which were discussed privately with respect to
nth-value, but i'm willing to believe that most of the time both
values will be used.)
B3. Yes, gross as multiple-value-psetq might be. If we are going to
call it multiple-value-setq, we should do it up consistently.
B7. CONVENTION.
Probably not a good idea.
I think Moon said everything for on this topic. The NIL pathname
code is modeled pretty much after the Lisp machine code. It is in
fact modularized such that the stuff which is applicable to a
particular "convention" (in our simplified case, VMS FILES-11) is
totally distinct from the other stuff which knows how to open streams
etc. Similarly, i will be adding TOPS-20 and ITS "conventions" so
that we can get on with having NIL read files over the chaos net.
I could see having a pathname-convention function, but i'm not
sure that it is reasonable to do so unless at least some of the
possible returned values are standardized, and there might be
additional hair of some "conventions" being "subconventions" of
others.
∂06-Jun-83 1755 Walter.VanRoggen@CMU-CS-A Ballot B
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 6 Jun 83 17:54:30 PDT
Date: 6 June 1983 1817-EDT (Monday)
From: Walter van Roggen <Walter.VanRoggen@CMU-CS-A> (C410WV50)
To: Fahlman@cmu-cs-c
Subject: Ballot B
CC: common-lisp@su-ai
Message-Id: <06Jun83.181707.WV50@CMU-CS-A>
[B1] ok
[B2] yes
[B3] no
[B4a] yes. FLOAT-INTEGER-SIGNIFICAND seems to be new, though clear.
I don't remember why we're calling it a significand; what's wrong
with MANTISSA
[B4b] ok.
[B4c] yes, this is definitely worthwhile.
[B5] ok
[B6] yes
[B7] ok. Are we still going to have logical pathnames? I'd rather not
have to implement them, especially since the description & intent
don't seem clear to me (examples?). As I see them, most of their
functionality is provided with this new CONVENTION arg and by most
underlying file systems.
---Walter
∂06-Jun-83 1852 KMP@MIT-MC
Received: from MIT-MC by SU-AI with TCP/SMTP; 6 Jun 83 18:52:02 PDT
Date: 6 June 1983 21:54 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
To: Common-Lisp @ SU-AI
B1 Make both halves of a complex match in type: No opinion.
B2 Let SQRT, etc. return complex values: Yes.
I see no other choice. This is the generic name; if it doesn't do the
generic thing, then complex numbers in Common Lisp will be a joke.
For the case where Fateman worries that a correct (albeit complex)
answer from SQRT is the wrong thing, I don't see why he can't just
write his own error checking. I had a bit of trouble finding how you'd
do the declarations in my Colander edition; in Maclisp, however, I
would write something like:
(LAMBDA (X)
(DECLARE (FLONUM X))
(IF (MINUSP X) (ERROR "Arg is negative" X))
(FLONUM-IDENTITY (SQRT X)))
B3 Make MULTIPLE-VALUE-SETQ take multiple arg pairs: Yes.
I know people who'd probably write their own macro
to do this sort of thing if it weren't provided
primitively. Since it must be absolutely trivial
to implement, I'd just as soon people use a standard
name rather than force them to make up their own name
for what amounts to the exact same thing.
B4 FLOAT-SIGNIFICAND proposals: No opinion.
B5 Changes to READ arguments: No.
I am not sure I understand all the issues that are being dealt with,
but for the set that I have thought about (read eof in middle of object,
flushing extra close parens quietly at toplevel, flushing whitespace after
toplevel read, etc), I am fairly convinced that the SUBREAD/READ
distinction is a valid one in so far as I think that READ is being stretched
too far and I think that this extra argument for recursive-p will cause us
trouble later on.
If we had flavorized streams, I would suggest that all streams support
a :READ-TOPLEVEL message, such that
(SEND STANDARD-INPUT :READ-TOPEVEL #'READ)
was the thing to do to instantiate any read. Note that this doesn't force
one to write pairs of functions, since any reader can replace #'READ. The
:READ-TOPLEVEL thing would be responsible for peeking for EOF and exiting
quietly, for flushing toplevel parens and whitespace, etc. The reader itself
would just read characters and would err if an eof was encountered within.
This is essentially a variation of the way :RUBOUT-HANDLER works on the
LispM; the application is slightly different, but I expect it is the right
thing.
The problem one might expect to have with this is that people writing
normal user programs with toplevel READ calls such as:
(DEFUN PROMPT-AND-ADD-NUMBERS ()
(FORMAT T "~&Input numbers (end with a NIL): ")
(DO ((L NIL (CONS FORM L))
(FORM (READ) (READ)))
((NULL FORM) (APPLY #'+ L))))
will have to bite the bullet and admit they are calling a toplevel
READ. Hence, they would write:
... (FORM (SEND STANDARD-INPUT :READ-TOPLEVEL #'READ)
(SEND STANDARD-INPUT :READ-TOPLEVEL #'READ)) ...
which is admittedly a bit cumbersome.
Of course, we don't have message passing yet (do we? -- things change so
fast...), so it'd have to be slightly different syntax. I suggest
(READ-TOPLEVEL #'READ)
where, on the LispM, for example, you'd probably implement this as a call
to the stream with a :RUBOUT-HANDLER message.
Oh, there's one other thing that would make this a LOT more comfortable.
The LispM has a function called PROMPT-AND-READ which is a nice abstract
way of getting a prompt and doing a toplevel read with some datatype
checking built in. I suggest that if we had this function, people would
probably rarely use READ anyway, since its features are very much nicer.
In summary, all I'm doing is funneling a lot of other people's ideas
through in the form of an alternate proposal:
* Flush the RECURSIVE-P extra arg.
* Introduce a new function which can be called to do a toplevel READ so
that we don't need function pairs.
* Also introduce PROMPT-AND-READ as on the LispM which really does more
what people usually want anyway. (Specifying how to extend
PROMPT-AND-READ would also be helpful; I know it's extensible but I'm
not sure if the LispM people tell their users how).
B6 MERGE-PATHNAMES: Yes.
B7 CONVENTION Yes.
∂06-Jun-83 1946 Guy.Steele@CMU-CS-A Multiple-value-revenge of the Ballot
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 6 Jun 83 19:45:48 PDT
Date: 6 June 1983 2242-EDT (Monday)
From: Guy.Steele@CMU-CS-A
To: common-lisp@SU-AI
Subject: Multiple-value-revenge of the Ballot
B1. I favor eliminating the data type (COMPLEX type1 type2), and replacing
it by the type (COMPLEX type). This simplifies the type systems, and removes
an annoying glitch in the abbreviation mechanism, as Moon pointed out.
It does strike me as a bit strange, however, that we would provide the
specialized types (COMPLEX RATIONAL), (COMPLEX SHORT-FLOAT),
(COMPLEX SINGLE-FLOAT), (COMPLEX DOUBLE-FLOAT), and (COMPLEX LONG-FLOAT),
but not provide (COMPLEX T) [or at least (COMPLEX (AND NUMBER (NOT COMPLEX))) ].
I guess I could go either way on this one. If (COMPLEX T) is not supported,
then certainly the rules of floating-point contagion should apply.
B2. (sqrt -1) and friends. YES.
B3. multiple-value-setq takes multiple pairs. NO.
B4a. Double values from xxx-significand. Mildly opposed. We voted on
this before, as I recall.
B4b. float-digits and float-precision. Fine by me. They aren't needed
for printing, especially if B4c is approved. However, their existence makes
B4c easier to explain.
B4c. Restriction on FLOAT-INTEGER-SIGNIFICAND. YES. I wanted to impose
a limitation like this, but didn't figure out the correct formulation.
B5. Recursive-p in READ and friends. YES.
B6. merge-pathnames. YES.
B7. file name convention argument. Mild YES.
--Guy
∂06-Jun-83 2006 Guy.Steele@CMU-CS-A MANTISSA => SIGNIFICAND
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 6 Jun 83 20:02:23 PDT
Date: 6 June 1983 2258-EDT (Monday)
From: Guy.Steele@CMU-CS-A
To: Walter van Roggen <Walter.VanRoggen@CMU-CS-A> (C410WV50)
Subject: MANTISSA => SIGNIFICAND
CC: common-lisp@SU-AI
In-Reply-To: <06Jun83.181707.WV50@CMU-CS-A>
The reason for not using the term "mantissa" is that in its popular
use in the context of floating-point representations it is a misnomer.
Technically, a a
mantissa is the fractional part of a logarithm. The significand of a floating-
point number is not the fractional part of a logarithm (the exponent),
but a fraction by which the base raised to the exponent must be multiplied.
--Guy
∂06-Jun-83 2014 Guy.Steele@CMU-CS-A Re: sqrt(-1)
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 6 Jun 83 20:13:41 PDT
Date: 6 June 1983 2309-EDT (Monday)
From: Guy.Steele@CMU-CS-A
To: fateman%UCBKIM@UCB-VAX (Richard Fateman)
Subject: Re: sqrt(-1)
CC: common-lisp@SU-AI
In-Reply-To: <8306062018.8926@UCBKIM.ARPA>
(1+ fixnum) IS NOT NECESSARILY a fixnum in Common LISP. It is fairly important
to the user that it not be.
I'm reminded of Tom Lehrer's remark in his introduction to "New Math"
on his album "That Was the Year That Was": "In the New Math, on the other
hand, the *idea* is the important thing... *rather* than getting the right
answer."
If you're worried about the speed of code, then there are several ways
to use declarations to say what you mean:
(THE DOUBLE-FLOAT (SQRT D))
(SQRT (THE (SINGLE-FLOAT 0.0 ()) D))
for example. (The first guarantees the result of SQRT to be a double-float;
the second guarantees the argument to be a non-negative single-float.)
One can also use assertions if explicit run-time checking is desired.
Perhaps, Dick, you have failed to realize that it is proposed to treat
rational and floating-point complex numbers according to different rules.
With rationals, as with integers (fixnums plus bignums) in MacLISP,
the emphasis is on getting the one, true, mathematically correct answer,
no matter what it takes. With floating-point, the emphasis is on sacrificing
accuracy for speed (as well as finiteness of representation, as necessary
in the case of irrational computations), *but* on sacrificing that accuracy
in a predictable and controllable fashion. Common LISP's treatment of
floating-point is essentially the traditional one. Automatic coercion
is provided in the form of floating-point contagion rules, but these are
never used in the case where one writes Common LISP code in as type-stringent
a manner as one would be compelled to in a strongly-typed language such
as FORTRAN. In the absence of such contagion, Common LISP's treatment
of floating-point is entirely consistent with the usual usage, and in
particular is completely consistent with the proposed IEEE floating-point
standard.
--Guy
∂06-Jun-83 2100 FAHLMAN@CMU-CS-C Revenge of the Ballot
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 6 Jun 83 21:00:37 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 6 Jun 83 23:59:55 EDT
Date: Mon, 6 Jun 1983 23:59 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Dir LCSR Comp Facility <HEDRICK@RUTGERS>
Cc: common-lisp@SU-AI
Subject: Revenge of the Ballot
In-reply-to: Msg of 6 Jun 83 18:24:32 EDT from Dir LCSR Comp Facility <HEDRICK at RUTGERS.ARPA>
B1. OK. One possible disadvantage is that floating-point contagion
is not guaranteed to work. That is, floating point has an upper
bound, whereas bignum's don't. What would you do with
(COMPLEX 1E-5 ZILLION), where ZILLION is a very big bignum?
We would do the same thing as we would do in the case of (+ 1E-5 ZILLION).
We would try to float the ZILLION in this format, and if it was too
large to fit, we'd get a floating-overflow error.
∂06-Jun-83 2226 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN NTH-VALUE
Received: from MIT-MC by SU-AI with TCP/SMTP; 6 Jun 83 22:26:14 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Tue 7-Jun-83 01:16:57-EDT
Date: Tuesday, 7 June 1983, 01:10-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: NTH-VALUE
To: common-lisp@SU-AI
Even though this was turned down and I don't see it as being a major
feature (just a minor one) I'll probably implement it next time I
feel like breaking a compiler. Then we'll see whether anyone uses it.
∂06-Jun-83 2301 GJC@MIT-MC
Received: from MIT-MC by SU-AI with TCP/SMTP; 6 Jun 83 23:01:00 PDT
Date: 7 June 1983 02:03 EDT
From: George J. Carrette <GJC @ MIT-MC>
To: Common-Lisp @ SU-AI
I still haven't seen a convincing argument for why disallowing
mixed-type complexes is needed for efficiency reasons.
Given the generic arithmetic operators on non-complex numbers this
restriction of form only makes my implementations more complicated
and slower. I humbly submit that machines with complex-floating-point
datatypes built-in can uses those instructions, and complicate
their implementation, since it is worth it, and they can do it
*without* requiring universal restrictions. It is a fairly
standard sort of optimization.
How about somebody giving a good argument here rather than a
"I'm told that, but I really don't have the ... to know."
It is somewhat puzzling that we have this uniformity rule embraced,
at the same time we have #C(3 0) => 3, a rule which surely breaks
some *easy* data-uniformity optimizations, although it certainly doesn't
require that #C(3 0) always be stored as 3, only that it never escapes
to the user as #C(3 0). Get my drift?
On the subject of (SQRT -1.0), let us consider Macsyma, a program
much used, even for floating point calculations. It never seemed
to bother people that Macsyma had rational and complex numbers
(of a sort), since sometimes it made for serendipity -- but
errors are eventually caught -- and presumably it will be easier
to DEBUG a program in common-lisp than in fortran, so the more
powerful operators in CL can be forgiven. In any case the
Macsyma *compiler* I wrote had two things, a switch
TR←FLOAT←CAN←BRANCH←COMPLEX, somewhat of a kludge, and a form
MODE←IDENTITY, like common-lisp's "THE."
So people could write MODE←IDENTITY(FLOAT,SQRT(X)).
They didn't mind the greater verbosity because they had Emacs...
My attitude is that these features, such as "/" returning a rational,
*cost* a certain amount, in changing code, and runtime perhaps, so
that once we (our users) pay this price we (our users) aught to get
the greatest flexibility for it.
So here we have a rule about uniformity of complex numbers. What does
it cost?
(1) More documentation to read.
(2) More runtime checking when making complex numbers.
(3) Reduction in possible objects to manipulate.
What are the universal benefits? (Non-universal ones should be
gotten by restrictive declarations in my book.)
∂06-Jun-83 2343 GSB@MIT-ML [Re: revenge of the ballot, B7]
Received: from MIT-ML by SU-AI with TCP/SMTP; 6 Jun 83 23:43:00 PDT
Date: 7 June 1983 02:44 EDT
From: Glenn S. Burke <GSB @ MIT-ML>
Subject: [Re: revenge of the ballot, B7]
To: KMP @ MIT-MC
cc: common-lisp @ SU-AI, fahlman @ CMU-CS-C
Kent pointed out that i referred to Moon's comments on
pathname-convention and came up with a negative reply, unlike Moon.
This is because (based on those arguments) the original reason for it
does not hold up. And while pathname-convention may not be an
unreasonable thing to have, we would have to standardize on what it
returned for it to be useful, and that could get complicated if you
tried to allow perturbations of standard "conventions" (and
"subtyping" of them etc.). I'm not against that, but it might even
mean yet-another-ballot.
∂07-Jun-83 0013 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN [Re: revenge of the ballot, B7]
Received: from MIT-MC by SU-AI with TCP/SMTP; 7 Jun 83 00:13:45 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Tue 7-Jun-83 03:15:21-EDT
Date: Tuesday, 7 June 1983, 03:09-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: [Re: revenge of the ballot, B7]
To: Glenn S. Burke <GSB%MIT-ML@SU-DSN>
Cc: KMP%MIT-MC@SU-DSN, common-lisp@SU-AI, fahlman%CMU-CS-C@SU-DSN
In-reply-to: The message of 7 Jun 83 02:44-EDT from Glenn S. Burke <GSB at MIT-ML>
Date: 7 June 1983 02:44 EDT
From: Glenn S. Burke <GSB @ MIT-ML>
Kent pointed out that i referred to Moon's comments on
pathname-convention and came up with a negative reply, unlike Moon.
I came up with a negative reply too, but I'm such a spastic that
I typed "yes" when I meant "no". Sorry about that.
∂07-Jun-83 0146 KMP@MIT-MC
Received: from MIT-MC by SU-AI with TCP/SMTP; 7 Jun 83 01:43:21 PDT
Date: 7 June 1983 04:44 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
To: fahlman @ CMU-CS-C
cc: Common-Lisp @ SU-AI
Sorry, I mistook Moon's "yes" to be a note of support for the CONVENTIONS
issue. To avoid further confusion on this issue, please just ignore my "yes"
vote and consider Moon to have my proxy on this one... The LispM crowd has
had hands-on experience with a multi-file-system pathname system for several
years now and probably has the best insight into what's going to be needed.
∂07-Jun-83 1430 @USC-ECL,@MIT-MC:BSG%SCRC-TENEX@MIT-MC DEFCONSTANT
Received: from USC-ECL by SU-AI with TCP/SMTP; 7 Jun 83 10:22:39 PDT
Received: from MIT-MC by USC-ECL; Tue 7 Jun 83 10:23:18-PDT
Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Tue 7-Jun-83 13:22:11-EDT
Date: Tuesday, 7 June 1983, 13:21-EDT
From: Bernard S. Greenberg <BSG%SCRC-TENEX@MIT-MC>
Subject: DEFCONSTANT
To: common-lisp%su-ai@usc-ecl
(Symbolics common-lisp-implementors may type D without reading: rephrase of Sat.'s flame.)
I am perturbed about DEFCONSTANT. According to the Laser manual,
DEFCONSTANT is just like DEFPARAMETER, but the compiler is free
to write the new value into object code.
While this sounds at first like an improvement, a more powerful
form of DEFPARAMETER, it is in fact a RESTRICTED form of
DEFPARAMETER. The issue of what-gets-put in the @i(initial-value)
slot is a subtle one. All well and good for
(defconstant foo 3),
but how about
(defconstant bar 6)
(defconstant foo (+ bar 6)),
which is legal, meaningful, common, useful, and non-problematic for
DEFPARAMETER? How is (+ bar 6) supposed to be evaluated at compile
time? (Note that DEFCONSTANT does this evaluation at load time, which
is what you "really" want). If the compiler were to use EVAL, does
that mean that bar was set at compile time by the first DEFCONSTANT,
so that this might be meaningful? If the binding were in some "compiler
temporary declaration", (such as the Lisp Machine compiler uses for
macros defined in a file being compiled) EVAL could not be used.
Compiling a file is NOT supposed to side-effect the environment.
The use of eval-when(compile) flags explicitly such attempts,
but does not make them harmless. Each such use has to be
deliberated very carefully, to prevent making impossible the
compilation of an incompatible version of the program.
Do you have to say
(eval-when (compile load eval) (defconstant bar 6))
(defconstant foo (+ bar 6))
to get meaningful results? Is this what we want? Should the
DEFCONSTANT documentation discuss and recommend this?
I will not even address the issue of
(defun f (x) ..)
(defconstant a (f 4))
but just throw it out for sport....
I think the use of DEFCONSTANT involves a tremendous amount of subtlety.
It may be reasonable to restrict the @i(initial-value) operand of
DEFCONSTANT to quoted or self-evaluating constants if the programmer
(and the compiler) are to have any hope of figuring out what is going
on.
∂07-Jun-83 1432 FAHLMAN@CMU-CS-C Testing
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 7 Jun 83 12:10:31 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 7 Jun 83 15:06:54 EDT
Date: Tue, 7 Jun 1983 15:06 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: common-lisp@su-ai
Subject: Testing
The mail giving the results of Ballot-B seems to be slow in making it
through SU-AI. This is a test to see if that pathway is down, sluggish,
or OK.
∂07-Jun-83 1431 FAHLMAN@CMU-CS-C Results of ballot B
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 7 Jun 83 10:56:20 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 7 Jun 83 13:55:41 EDT
Date: Tue, 7 Jun 1983 13:55 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: common-lisp@su-ai
Subject: Results of ballot B
Results of Ballot B:
---------------------------------------------------------------------------
B1. Proposed that we require both halves of a complex number to be of
the same type, either both rationals or both floats of the same type:
APPROVED.
---------------------------------------------------------------------------
B2. Return a complex number from functions like (sqrt -1), where we
would otherwise have to signal an error: APPROVED. Implementations are
free to invent real-value-only functions or a *REAL-VALUES-ONLY* switch
if they so choose.
---------------------------------------------------------------------------
B3. MULTIPLE-VALUE-SETQ must take argument pairs like SETQ does:
REJECTED.
---------------------------------------------------------------------------
B4a. Remove FLOAT-EXPONENT and FLOAT-INTEGER-EXPONENT, and return those
numbers as the second values from FLOAT-SIGNIFICAND and
FLOAT-INTEGER-SIGNIFICAND: APPROVED.
Now we need a new name for this. The best that Moon and I have been
able to come up with is DECODE-FLONUM. PARSE-FLONUM says the right
thing, but is very confusing. Any other suggestions? I will send out a
mini-ballot on this and on whether this function should return the sign
as a third value, flushing FLOAT-SIGN.
B4b. Add new functions FLOAT-DIGITS and FLOAT-PRECISION: APPROVED.
B4c. Require the result of FLOAT-INTEGER-SIGNIFICAND to reflect the
precision of the floating-point number: APPROVED.
---------------------------------------------------------------------------
B5. Add optional RECURSIVE-P argument to READ and friends: APPROVED.
There was some discussion of exactly what the error action should be in
recursive reads. I'll send out a proposal on this shortly.
---------------------------------------------------------------------------
B6. Rename MERGE-PATHNAME-DEFAULTS to MERGE-PATHNAMES and eliminate the
default-type argument: APPROVED.
---------------------------------------------------------------------------
B7. Propose that we add a new slot, CONVENTION, to the pathname
structure, and an optional CONVENTION argument to the PATHNAME and
TRUENAME functions: withdrawn by the proposer (me).
After considering Moon's arguments and some comments by Hedrick and
Burke, I no longer believe this to be a good idea, at least in anything
like the form proposed.
Long-winded explanation:
First, I am willing to accept that each known host follows exactly one
file-naming convention. (The manual needs to claify that "host" names a
file system, not a CPU.) Given a host, the convention can easily be
found by a simple lookup in a site-specific table. So the argument that
a convention slot in the pathname tells you how to print it, modify it,
etc., is just an efficiency hack.
Second, we must ask if there is a set of interesting cases where the
convention is known but the host is not. One can imagine such cases --
"I don't know what CMU-WOMBAT is, but this sure looks like a unix
namestring" -- but I can't think of any real context in which such
partial information would be both available and useful. As Moon points
out, there are not many cases in which the user would prefer to supply
the namestring convention explicitly.
Finally, there is the question of clarity. The real reason I favored
this is that it seemed to me that the parsing of a file-name had two
distinct phases, and it would make things much clearer if we separated
them. First, the implementation must dive in and extract a host name
from the namestring, and from that host name determine the convention.
Exactly how that host-name extraction works is implementation-dependent,
and will certainly change over time at most sites. It is a function of
the set of conventions that an implementation is prepared to recognize.
Some might just scan for anything before a "::", while others might also
look for [foo] or see if there is something like "foo:" where "foo" is
in the table of recognized hosts. Given the host, one can then do the
site-dependent table lookup to determine the convention in effect.
THEN one would parse the namestring using this convention argument as a
guide. This parsing operation would be implementation-independent,
given that na implementation wants to provide for a given convention: we
would only need one unix-namestring parser, one ITS namestring parser,
etc.
So I was drawn to the separate convention machinery mostly by the
increased clarity of such an account over the current description. What
I now realize, however, is that if we want to make this boundary between
the two phases of namestring parsing visible to the user, we have to
standardize it. We have to provide a DETERMINE-CONVENTION function for
namestrings and specify all of the things that it might or must return.
We have to do this in such a way that we do not rule out extensions
which would make use of a hierarchical organization of conventions or of
partially-sepecified or ambiguous conventions. To do this in a standard
way is a task that we could not possibly complete in time for the
current manual, and it may not be a good idea in any event. Most
namestring parsers will have this two-layered structure, but the
potential variability of the interface between those layers is so great
that we probably want to let that be an issue between each
implementation and itself, at least for now.
So, unless there are objections, I propose that we forget about the
proposed convention argument to PATHNAME and TRUENAME, and that the
CONVENTION argument to PARSE-NAMESTRING should be specified to take a
known host-name: if this is supplied, the parsing will conform to the
conventions of that host. I think that gives us a sufficient escape
hatch for odd cases.
∂07-Jun-83 1442 FAHLMAN@CMU-CS-C
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 7 Jun 83 09:13:10 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 7 Jun 83 12:11:47 EDT
Date: Tue, 7 Jun 1983 12:11 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: George J. Carrette <GJC@MIT-MC>
Cc: Common-Lisp@SU-AI
In-reply-to: Msg of 7 Jun 1983 02:03 EDT from George J. Carrette <GJC at MIT-MC>
You ask about the advantages of requiring complex numbers to be
homogeneous in type. You calim that the cost of making this move is
(1) More documentation to read.
(2) More runtime checking when making complex numbers.
(3) Reduction in possible objects to manipulate.
Now, being a mere Lisp hacker and less mathematical than most, I cannot
claim to understand these things, but let me take a stab at listing the
advantages anyway:
(1) Less and simpler documentation to read. Mixed types lead to
complexity in the declaration system, at least. Also, I believe
that users would find mixed-type complexes confusing -- I do.
(2) Possibly greater runtime efficiency. Whenever you operate on a
mixed-type complex (except for addition and subtraction), you have
to do type-contagion at that point. With this restriction,
implementations have the option to do the contagion once, when the
number is created.
(3) Reduction in possible objects to manipulate. With only the useful
complex types around, and not ones that turn into homogeneous types
when you use them but have to be kept in their original form
otherwise, the few remaining types can receive more of the
implementor's attention in the area of making them efficient.
-- Scott
∂07-Jun-83 1439 @USC-ECL,@MIT-MC:BSG%SCRC-TENEX@MIT-MC Pathname Conventions
Received: from USC-ECL by SU-AI with TCP/SMTP; 7 Jun 83 07:23:18 PDT
Received: from MIT-MC by USC-ECL; Tue 7 Jun 83 07:25:25-PDT
Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Tue 7-Jun-83 10:09:52-EDT
Date: Tuesday, 7 June 1983, 10:09-EDT
From: Bernard S. Greenberg <BSG%SCRC-TENEX@MIT-MC>
Subject: Pathname Conventions
To: Common-Lisp%SU-AI@USC-ECL
While all of Moon's observations on this subject are correct and
reflect our experience, I nevertheless think it would be quite
unwise to nail down the host/pathname-parsing relationship into
the standard at this time. The corresponding set of features in
the Lisp Machine system at this time is the subject of an ongoing
debate, and in my mind, no proposed solution to the problems
involved has overriding merit.
In general, I feel queasy about the specification of the pathname
system being in the spec at all. I think it is premature.
∂07-Jun-83 1528 Walter.VanRoggen@CMU-CS-A Re: DEFCONSTANT
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 7 Jun 83 15:27:48 PDT
Date: 7 June 1983 1820-EDT (Tuesday)
From: Walter van Roggen <Walter.VanRoggen@CMU-CS-A> (C410WV50)
To: Bernard S. Greenberg <BSG%SCRC-TENEX@MIT-MC>
Subject: Re: DEFCONSTANT
CC: common-lisp@su-ai
In-Reply-To: "Bernard S. Greenberg's message of 7 Jun 83 12:21-EST"
Message-Id: <07Jun83.182018.WV50@CMU-CS-A>
My idea of how DEFCONSTANT should work is similar to how DEFMACRO works.
Each DEFCONSTANT has an implied EVAL-WHEN (COMPILE LOAD EVAL) around it.
For most simple constants, yes, this is like DEFPARAMETER. But we
definitely want to be able to have compile time constants available for
the compiler to optimize on. That means we have to give up some sharing.
For example,
(defconstant eof-marker '(eof-marker))
(defun foo () eof-marker)
(defun bar () eof-marker)
and now (EQ (FOO) (BAR)) is not necessarily true. I think this is why
we had to rename DEFCONST to DEFCONSTANT. I guess some examples in
the manual would help.
---Walter
∂07-Jun-83 1934 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN Re: DEFCONSTANT
Received: from MIT-MC by SU-AI with TCP/SMTP; 7 Jun 83 19:34:36 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Tue 7-Jun-83 22:26:18-EDT
Date: Tuesday, 7 June 1983, 22:16-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Re: DEFCONSTANT
To: Walter van Roggen <Walter.VanRoggen%CMU-CS-A@SU-DSN>
Cc: common-lisp@su-ai
In-reply-to: <07Jun83.182018.WV50@CMU-CS-A>
Date: 7 June 1983 1820-EDT (Tuesday)
From: Walter van Roggen <Walter.VanRoggen@CMU-CS-A> (C410WV50)
My idea of how DEFCONSTANT should work is similar to how DEFMACRO works.
Each DEFCONSTANT has an implied EVAL-WHEN (COMPILE LOAD EVAL) around it.
The issue here is that if you do that the value of the variable (constant)
gets changed in the Lisp in which you are running the compiler. This
certainly has to be documented, and could be a serious problem if you are
changing the value of a constant; suppose that the constant is something
that is needed in order to run the compiler or the reader or some other
low-level part of the Lisp system. For a concrete example, let's say
that it's the value of some field in the readtable that means "open
parenthesis." The only thing that is likely to save you is if all
references to the constant were actually open-coded, and no important
code is being run interpreted.
Those of you on the list who use cross-compilers, rather than compiling
in the Lisp environment in which you actually do your work, may not yet
appreciate all the ways you can get into trouble by having the act of
compiling a file (without loading it) change things in your Lisp world.
The choices I see are (in no particular order):
(1) DEFCONSTANT has an implied EVAL-WHEN (COMPILE LOAD EVAL) around it and
hence compiling anything with a DEFCONSTANT in it is just like loading it.
(2) A special constant-values table is set up by DEFCONSTANT and used by
the compiler in certain contexts that have to be carefully documented. The
important thing is that these constant values are not seen by the interpreter
and not seen by SYMBOL-VALUE. This is very similar to the way the compiler
treats macros, where MACROEXPAND searches the special table of macros that
have been seen during the compilation, but EVAL doesn't.
(3) DEFCONSTANTs are executed at compile time, but the values are restored
after the compilation completes (perhaps a dynamic binding is created by the
compiler when it sees a DEFCONSTANT, and the rest of the compilation runs
inside of that binding.)
(4) It is illegal to use a DEFCONSTANT in any but certain restricted
contexts, i.e. compiling references to it. If you want it to be
available to the interpreter during compilation, you must explicitly put
in an EVAL-WHEN and face the consequences to the environment in which
you are running the compiler. This is very similar to the way the
compiler treats defuns.
∂07-Jun-83 2241 FAHLMAN@CMU-CS-C DEFCONSTANT
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 7 Jun 83 22:40:57 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 8 Jun 83 01:40:40 EDT
Date: Wed, 8 Jun 1983 01:40 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: David A. Moon <Moon%SCRC-TENEX@MIT-MC>
Cc: common-lisp@su-ai
Subject: DEFCONSTANT
In-reply-to: Msg of 7 Jun 1983 22:16-EDT from David A. Moon <Moon%SCRC-TENEX%MIT-MC at SU-DSN>
I guess I hadn't realized that there was a problem here. In Spice we
will probably spawn a second Lisp process whenever we want to compile a
file, though compilation of individual functions may be done within the
Lisp where we live. The latter operation tends not to hit DEFCONSTANTs.
I see no compelling reason why DEFCONSTANT values have to be available
to EVAL during a compilation, as long as we carefully document that. As
you say, if some such value must be available to a macro-expander
function, the user can put it in an explicit EVAL-WHEN COMPILE and take
his lumps. We might discover that the EVAL-WHEN form gets used so often
that we want to make it a standard macro with a different name, but I
bet it won't.
Note also that if a DEFCONSTANT contains something that the compiler
can't figure out at compile time, the compiler can just decline to
open-code references to this constant and can code the reference as a
normal special. The variable will get its value at load-time and
everythign will work correctly, though perhaps more slowly than the user
expected. Just how clever the compiler has to be is something that we
should leave up to the implementor. We do not want the white pages to
say that certain things must be open-coded. Even a quoted constant
might not want to be open-coded if it is a huge list and the user has
asked the compiler to optimize for size.
I think this is Moon's option 2, though it might be 4 -- I'm not sure I
grasp the difference. I could live with 1 (go ahead and clobber the
variable), since we don't compile where we live anyway. Option 3,
binding and unbinding the things a compilation might zap, strikes me as
too hard to implement.
-- Scott
∂07-Jun-83 2250 Guy.Steele@CMU-CS-A Re: DEFCONSTANT
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 7 Jun 83 22:50:24 PDT
Date: 8 June 1983 0146-EDT (Wednesday)
From: Guy.Steele@CMU-CS-A
To: Bernard S. Greenberg <BSG%SCRC-TENEX@MIT-MC>
Subject: Re: DEFCONSTANT
CC: common-lisp@SU-AI
In-Reply-To: "Bernard S. Greenberg's message of 7 Jun 83 12:21-EST"
The initial-value form to DEFCONSTANT is conceptually evaluated at load
time. DEFCONSTANT is an invitation to the compiler to susbtitute the
value for occurrences of the constant *if* the compiler is smart enough
to do so. DEFCONSTANT is not meant to side-effect the compiler's environment.
(DEFCONSTANT FOO 3)
(DEFCONSTANT BAR (+ FOO 6))
entitles the compiler to use the value 9 for BAR provided that it is
smart enough to analyze what it going on (actually notall that hard:
the first declaration entitles the compiler to substitute 3 for FOO,
whereupon some simple constant folding reduces (+ 3 6) to 9).
--Guy
∂07-Jun-83 2345 KMP@MIT-MC DEFCONSTANT, etc
Received: from MIT-MC by SU-AI with TCP/SMTP; 7 Jun 83 23:45:13 PDT
Date: 8 June 1983 02:47 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
Subject: DEFCONSTANT, etc
To: Common-Lisp @ SU-AI
Please note that (shudder) even though the value of the constant
of FOO in (DEFCONSTANT FOO val) is not accessible except during
compilation, any side effects done during the computation of val,
eg, (DEFCONSTANT FOO (PUTPROP 'BAR '(BAZ) 'SOME-PROP)) will be
available if the decision is made to do compile-time evaluation,
so the problem on the LispM of side-effecting the runtime environment
is a real one.
I am still bothered that on the LispM, the compiler does a
side-effect to my compile-time environment when it sees DEFSETF,
for example.
The issue of separation of runtime and compile time environments is
a big one and I would suggest that there is probably a more orderly
way of proceeding in this discussion rather than poking at the details
of DEFSETF. Maybe we could make this discussion more general and
talk first about what the effect of a compilation is on the compilation
time environment.
Also, one of the choices on Moon's (I think) list of 4 options of what
to do with DEFCONSTANT said "DEFCONSTANTs are executed at compile time,
but the values are restored after the compilation completes." I'm
surprised he posed this; maybe he doesn't believe it, or maybe he has a
better theory of this than I do, but in an environment as on the LispM
where incremental compilation is possible, the idea of a compilation
being "complete" and of persistence of assumptions is muddied
considerably.
In any case, if Common Lisp took a definite stand on generalizations about
how the compiler and interpreter relate to one another, it would probably
be easier to answer questions like the one about DEFCONSTANT.
Also, it would be easier to think about DEFCONSTANT if someone posed some
real examples of where they would want to use it. What its semantics should
be is intimately tied to how it is suggested it be used. I find it hard to
think usefully about scenarios of what (DEFCONSTANT FOO 3) should mean.
--kmp
∂08-Jun-83 0756 FAHLMAN@CMU-CS-C DEFCONSTANT
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 8 Jun 83 07:55:51 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 8 Jun 83 09:55:02 EDT
Date: Wed, 8 Jun 1983 09:55 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: common-lisp@su-ai
Subject: DEFCONSTANT
A key question concerning DEFCONSTANT is whether two uses of the same
constant must produce values that are EQ. Consider the following silly
code fragment:
(defconstant foo '(rabid wombat))
(defun bar () foo)
(defun bletch () foo)
(defun urgh () (eq (bar) (bletch)))
Compile this and call URGH. If DEFCONSTANT has to work EXACTLY like
load-time SETQ, then URGH is guaranteed to return T. This is the
intuitive thing. However, if we require this, then it would take a very
wily compiler indeed to ever do any compile-time substitution. Even if
the URGH function were not present in the compiled file, the user could
come along and write it at runtime. References that get consumed within
a compiled function and not passed on out of it would be OK, but this is
a new class of things to worry about. Adding something to a constant
consumes it, but consing it into a list does not -- someone could still
check for EQ on the constituent.
Under these rules, our compiler would substitute for constant fixnum
values, characters, symbols, and nothing else. The key question is
whether the init form does any consing without "consuming" the result;
we would just be lazy and panic at the first sight of a cons or unknown
form. (We'd probably try to find a loophole by which we could include
byte specifiers, but this is tricky since we use CONSes for them right
now.) Note that if we replace '(rabid wombat) with 3.1415L0, in an
implementation where this number is consed, we cannot do the
substitution either, as long as URGH is supposed to return T.
The above "intuitive" rules allow up about 90% of the places where you'd
really like compile-time substitution -- fixnums are by far the most
important case -- but leaves out constant lists, simple strings, and
consed numbers. These could still appear in DEFCONSTANT, but you'd have
to do a special-variable reference to get at them.
We could instead state in the manual that two references to a constant
symbol are not guaranteed to be EQ, and if you want EQ values you should
use DEFVAR or DEFPARAMETER. This could be explained as a sort of macro:
references to the symbol in compiled code are replaced (or can be
replaced) with the init form, quoted. The init form is also evaluated
at load time and the constant is bound to the result, so
special-variable references to it at runtime work properly.
I slightly favor the latter approach, since it greatly increases the
utility of DEFCONSTANT and allows for all sorts of optimizations to
occur. However, it is non-intuitive for the average user. I could go
either way on this. I think that some of the implications for program
verifiers and the like could be pretty deep -- referential transparency
and all of that.
Opinions?
-- Scott
∂08-Jun-83 0950 Walter.VanRoggen@CMU-CS-A
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 8 Jun 83 09:49:59 PDT
Date: 8 June 1983 1150-EDT (Wednesday)
From: Walter van Roggen <Walter.VanRoggen@CMU-CS-A> (C410WV50)
To: common-lisp@su-ai
Message-Id: <08Jun83.115058.WV50@CMU-CS-A>
- - - - Begin forwarded message - - - -
Date: 8 June 1983 1147-EDT (Wednesday)
From: Walter van Roggen <Walter.VanRoggen@CMU-CS-A> (C410WV50)
To: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Re: DEFCONSTANT
In-Reply-To: "David A. Moon's message of 7 Jun 83 21:16-EST"
Message-Id: <08Jun83.114703.WV50@CMU-CS-A>
Indeed, I have occasionally had problems with the compiler environment
getting altered undesirably; DEFMACRO has the same effects you describe.
Unlike what you say in (2), I believe that macros do get put into the
compiler's environment. So the potential problems with DEFCONSTANT as I
saw them are no different. In any case, I had hoped packages would
help avoid confusion when compiling the compiler or the lisp system.
But apparently the intent of DEFCONSTANT (according to Guy) is different
from all 4 options you list: it's like DEFPARAMETER with an implicit
declaration saying "if you can figure out what the value is without
changing the semantics (i.e., not copying), go ahead and use it, else
use the load-time value (which should be the same as just referring
to the special value, since it's constant)".
I'm happy with that definition. I just thought the one that corresponds
to DEFMACRO is also very useful and deserves its own name;.
---Walter
- - - - End forwarded message - - - -
∂08-Jun-83 0958 FAHLMAN@CMU-CS-C Loose ends
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 8 Jun 83 09:58:08 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 8 Jun 83 12:58:35 EDT
Date: Wed, 8 Jun 1983 12:58 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: common-lisp@su-ai
Subject: Loose ends
Just a couple of loose ends to tie up. I am swapping out for a few days
and Guy may be in a position to finish up a draft of the manual before I
return, so I would like to just propose a couple of things that will go
in if nobody objects by the time he gets to them. I think that these
proposals will be uncontroversial, but I've been wrong before on such
issues.
1. FLOAT-SIGNIFICAND and FLOAT-INTEGER-SIGNIFICAND are now confusing
names, given the change in semantics approved by the last ballot.
I propose that these be called DECODE-FLOAT and INTEGER-DECODE-FLOAT,
unless a better name is proposed within the next 24 hours or so. I
propse that the determination of "better" will be done by Guy.
2. Whatever we call the functions listed above, it is proposed that they
return a third value which is the sign of the number, in the format
currently supplied by a one-arg call to FLOAT-SIGN. The rationale is
similar to the rationale for combining the significand and the exponent:
whenever you want any of these, you almost always want all of them. I
suggest that we leave it up to Guy to decide whether, given this change,
FLOAT-SIGN is useful enough to keep.
3. People have aksed for a clarification of the RECURSIVEP argument (I
guess given the hyphen rules, this should not be RECURSIVE-P after all)
to read and friends. The following items are affected:
a. Top-level calls rebind the ## environment; recursive calls don't.
b. Top-level calls establish the preserve-whitespace flag; recursive
calls observe this but don't change it.
c. Top-level calls establish the action to be taken if end-of-file is
read. I have no objection to Moon's suggestion that an error in a
recursive read, if it is in the middle of an object, always signals
an "eof in middle of object" error. I am not sure whether a
recursive call would ever have to handle an eof that would not want
to cause such an error, but if so, the top-level eof switches should
control the action. A bit more thought is needed here to decide just
how to state this.
d. In some implementations, a great deal of efficiency can be gained by
checking certain things at top-level and not at every recursive call.
(An example is pre-processing the stream into something lower-level
for use within the call.) The RECURSIVEP argument provides some
necessary information for such decisions.
It would of course be possible to eliminate the RECURSIVEP argument and
to do the same thing with a special variable -- this is true of every
argument to every Lisp function. If we do that, we would have to
document this variable so that error handlers and character macros that
want to establish a new top-level dialogue can rebind it to its
top-level value. (That would be a rare occurrence, but one that we
ought to allow for.) We could have gone this way, but the necessary
machinery is nearly identical, so I see no reason to re-open the
argument. Let's stick with the RECURSIVEP argument.
∂08-Jun-83 1142 @MIT-MC:BSG%SCRC-TENEX%MIT-MC@SU-DSN DEFCONSTANT
Received: from MIT-MC by SU-AI with TCP/SMTP; 8 Jun 83 11:42:22 PDT
Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Wed 8-Jun-83 14:13:01-EDT
Date: Wednesday, 8 June 1983, 14:11-EDT
From: Bernard S. Greenberg <BSG%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: DEFCONSTANT
To: Walter.VanRoggen%CMU-CS-A@SU-DSN, common-lisp@su-ai
In-reply-to: <08Jun83.115058.WV50@CMU-CS-A>
Date: 8 June 1983 1147-EDT (Wednesday)
From: Walter van Roggen <Walter.VanRoggen@CMU-CS-A> (C410WV50)
Indeed, I have occasionally had problems with the compiler environment
getting altered undesirably; DEFMACRO has the same effects you describe.
Unlike what you say in (2), I believe that macros do get put into the
compiler's environment. So the potential problems with DEFCONSTANT as I
saw them are no different. In any case, I had hoped packages would
help avoid confusion when compiling the compiler or the lisp system.
Indeed. The Lisp Machine's compiler DOES NOT evaluate macro definitions
at compile time, but effectively remembers them as local declarations,
local to the file being compiled. They are saved in a place where
MACROEXPAND knows how to find them. So on the Lisp Machine, the non-existent
sins of DEFMACRO are not an excuse for similar behavior by DEFCONSTANT.
Liber Laserum says only "the macro is added to the compilation environment",
which is noncommital.
The direct parent of Lisp Machine Lisp, MacLisp, indeed solved these
problems via packages. Programs being compiled were compiled in a package
(one of two) where none of the compiler's internal symbols were accessible.
You could compile incompatible compilers with all the eval-when's you wanted,
without any fear of breaking the compiler. The Lisp Machine (and Common Lisp)
package systems, although far more general, do not enjoy this feature. This
is the reason at the root of why we don't eval-when(compile) macros.
eval-when(compile) is not an object for trepidation in an environment
where the program being compiled lives in its own namespace, or in a
batch compilation environment (the compiler is a separate program that you
invoke from operating system command level), which is effectively the same thing.
Even the Lisp Machine has two paradigms of compilation that are diametrically
opposed on the issue of compilation side effects. When we compile files,
we do so in such a way as to minimize side effect. When we compile
editor buffers or pieces of editor buffers, we do so in such a way as to
maximize side effect. Specifically, we "load" each top-level form
immediately after we have compiled it. In this latter scenario, ALL
of my supposedly problematic DEFCONSTANT examples do the "right thing".
I tend to agree with KMP that the language spec needs work in the area of
compile/load interactions, compilation environment mungs, etc. I think
the language should either define behavior precisely or state what freedom
of choice is open to the implementation. Defining precise behavior might
mean that somebody has to turn their implementation inside out, while
permitting enough freedom so that nobody has to turn their implementation
inside out might, for instance, make DEFCONSTANT unspecifiable and/or
unimplementable.
∂08-Jun-83 1213 @MIT-MC:MOON@SCRC-TENEX Loose ends
Received: from MIT-MC by SU-AI with TCP/SMTP; 8 Jun 83 12:13:47 PDT
Date: Wednesday, 8 June 1983 14:02-EDT
From: MOON at SCRC-TENEX
to: common-lisp at su-ai
Subject: Loose ends
In-reply-to: The message of Wed 8 Jun 1983 12:58 EDT from Scott E. Fahlman <Fahlman@CMU-CS-C>
This is all okay with me.
∂08-Jun-83 1235 @MIT-MC:BSG%SCRC-TENEX%MIT-MC@SU-DSN Re: DEFCONSTANT
Received: from MIT-MC by SU-AI with TCP/SMTP; 8 Jun 83 12:35:18 PDT
Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Wed 8-Jun-83 14:47:26-EDT
Date: Wednesday, 8 June 1983, 14:46-EDT
From: Bernard S. Greenberg <BSG%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Re: DEFCONSTANT
To: Guy.Steele%CMU-CS-A@SU-DSN
Cc: common-lisp@SU-AI
In-reply-to: The message of 8 Jun 83 01:46-EDT from Guy.Steele at CMU-CS-A
Date: 8 June 1983 0146-EDT (Wednesday)
From: Guy.Steele@CMU-CS-A
The initial-value form to DEFCONSTANT is conceptually evaluated at load
time. DEFCONSTANT is an invitation to the compiler to susbtitute the
value for occurrences of the constant *if* the compiler is smart enough
to do so. DEFCONSTANT is not meant to side-effect the compiler's environment.
(DEFCONSTANT FOO 3)
(DEFCONSTANT BAR (+ FOO 6))
entitles the compiler to use the value 9 for BAR provided that it is
smart enough to analyze what it going on (actually notall that hard:
the first declaration entitles the compiler to substitute 3 for FOO,
whereupon some simple constant folding reduces (+ 3 6) to 9).
--Guy
Ingenious! This seems to be the best of all possible worlds (I admit
candidly). Although I think, as per previous letters, the issue needs
some definitional and documentation-wise sorting out, this does seem
to solve all problems. The answer to "What kind of evaluator or meta-
evaluator should be invoked on the second operand of DEFCONSTANT?" is
"the compiler's pass-1 optimizer/reducer"! That is not something we
do now, but there is no good reason why not.
∂08-Jun-83 1427 @USC-ECL,@MIT-MC:BSG%SCRC-TENEX@MIT-MC UNDEFCONSTANT
Received: from USC-ECL by SU-AI with TCP/SMTP; 8 Jun 83 14:26:41 PDT
Received: from MIT-MC by USC-ECL; Wed 8 Jun 83 14:24:23-PDT
Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Wed 8-Jun-83 16:20:56-EDT
Date: Wednesday, 8 June 1983, 16:19-EDT
From: Bernard S. Greenberg <BSG%SCRC-TENEX@MIT-MC>
Subject: UNDEFCONSTANT
To: common-lisp%su-ai@usc-ecl
The loading of a DEFCONSTANT changes the symbol being defined
in a (so far) unalterable fashion. There ought to be an
in-language way to revoke this effect.
∂08-Jun-83 1602 @MIT-ML:Cassels%SCRC-TENEX%MIT-ML@SU-DSN Loose ends
Received: from MIT-ML by SU-AI with TCP/SMTP; 8 Jun 83 16:02:03 PDT
Received: from SCRC-HOUSATONIC by SCRC-TENEX with CHAOS; Wed 8-Jun-83 19:00:19-EDT
Date: Wednesday, 8 June 1983, 18:58-EDT
From: Robert A. Cassels <Cassels%SCRC-TENEX%MIT-ML@SU-DSN>
Subject: Loose ends
To: Fahlman%CMU-CS-C@SU-DSN, common-lisp@su-ai
In-reply-to: The message of 8 Jun 83 12:58-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: Wed, 8 Jun 1983 12:58 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
Just a couple of loose ends to tie up. I am swapping out for a few days
and Guy may be in a position to finish up a draft of the manual before I
return, so I would like to just propose a couple of things that will go
in if nobody objects by the time he gets to them. I think that these
proposals will be uncontroversial, but I've been wrong before on such
issues.
1. FLOAT-SIGNIFICAND and FLOAT-INTEGER-SIGNIFICAND are now confusing
names, given the change in semantics approved by the last ballot.
I propose that these be called DECODE-FLOAT and INTEGER-DECODE-FLOAT,
unless a better name is proposed within the next 24 hours or so. I
propse that the determination of "better" will be done by Guy.
2. Whatever we call the functions listed above, it is proposed that they
return a third value which is the sign of the number, in the format
currently supplied by a one-arg call to FLOAT-SIGN. The rationale is
similar to the rationale for combining the significand and the exponent:
whenever you want any of these, you almost always want all of them. I
suggest that we leave it up to Guy to decide whether, given this change,
FLOAT-SIGN is useful enough to keep.
There is probably still some use for the two-argument FLOAT-SIGN. I do
agree that the functions in (1.) should return the sign as a third
value.
I guess I would like to amend slightly my proposal on FLOAT-DIGITS and
FLOAT-PRECISION, to combine them into a single function returning two
values, for reasons similar to those which led to combining
FLOAT-SIGNIFICAND, etc. But I don't feel strongly about it or the names
I proposed and am willing to leave it to Guy's judgement. (Guy -- you
wondered why I wanted this information for printing. It's strictly for
doing the thing suggested by the IEEE standard, where denormalized
numbers are printed with leading zeros.)
∂08-Jun-83 1606 GSB@MIT-ML Loose ends
Received: from MIT-ML by SU-AI with TCP/SMTP; 8 Jun 83 16:05:49 PDT
Date: 8 June 1983 19:07 EDT
From: Glenn S. Burke <GSB @ MIT-ML>
Subject: Loose ends
To: Fahlman @ CMU-CS-C
cc: common-lisp @ SU-AI
Fine by me.
∂08-Jun-83 1809 GSB@MIT-ML defconstant, eval-when, etc.
Received: from MIT-ML by SU-AI with TCP/SMTP; 8 Jun 83 18:09:20 PDT
Date: 8 June 1983 21:11 EDT
From: Glenn S. Burke <GSB @ MIT-ML>
Subject: defconstant, eval-when, etc.
To: common-lisp @ SU-AI
The one thing which needs to be clearly specified is how the semantics
of "added to the compilation environment" differs from what might be
done by (eval-when (compile) ...). If, for instance, defmacro does
not bash the runtime environment, then the user will have to use
eval-when if the macro needs to be usable via the interpreter during
the compilation. Eval-when should do exactly that: evaluate and bash
the runtime environment. Always, without exception, no matter what
"added to the compilation environment" might mean. My own experience
is that it is generally a loss for "added to the compilation
environment" to bash the runtime environment. Extracting necessary
declarative information from files in order to do multi-file
compilation carefully is not actually that difficult, and we have some
tools for doing this.
(I bring this up because i was just shafted by this in a very big way
bootstrapping LSB up in a lisp implementation which shall remain
nameless. Unfortunately the bootstrap procedure cannot use LSB
itself.)
∂08-Jun-83 2247 Guy.Steele@CMU-CS-A Re: DEFCONSTANT
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 8 Jun 83 22:47:30 PDT
Date: 9 June 1983 0100-EDT (Thursday)
From: Guy.Steele@CMU-CS-A
To: Scott E. Fahlman <Fahlman@CMU-CS-C>
Subject: Re: DEFCONSTANT
CC: common-lisp@SU-AI
In-Reply-To: "Scott E. Fahlman's message of 8 Jun 83 08:55-EST"
Regarding DEFCONSTANT and consed numbers, note that page 121 of
the Laser edition notes that "numbers are not true objects",
and cannot be relied upon to stay EQ. This is a special-case
hack, of course, intended to allow NCOMPLR-type tricks.
--Guy
∂09-Jun-83 1117 FISCHER@RUTGERS.ARPA Re: [Scott's message about EQ DEFCONSTANTs]
Received: from RUTGERS by SU-AI with TCP/SMTP; 9 Jun 83 11:16:28 PDT
Date: 9 Jun 83 14:17:40 EDT
From: Ron <FISCHER@RUTGERS.ARPA>
Subject: Re: [Scott's message about EQ DEFCONSTANTs]
To: Fahlman@CMU-CS-C.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: Message from "Scott E. Fahlman <Fahlman@CMU-CS-C>" of 8 Jun 83 09:55:00 EDT
DEFCONSTANT is defined in the manual to produce values that are EQUALP
only. Not EQ.
(ron)
-------
∂09-Jun-83 1656 @MIT-MC:MOON@SCRC-TENEX Re: [Scott's message about EQ DEFCONSTANTs]
Received: from MIT-MC by SU-AI with TCP/SMTP; 9 Jun 83 16:46:34 PDT
Date: Thursday, 9 June 1983 19:44-EDT
From: MOON at SCRC-TENEX
To: common-lisp at su-ai
Subject: Re: [Scott's message about EQ DEFCONSTANTs]
Date: 9 June 1983 17:31 EDT
From: Communications Satellite <COMSAT @ MIT-MC>
FAILED: common-lisp at SU-AI; Recipient name apparently rejected.
Last reply was: {500 Syntax error in recipient specification.}
Failed message follows:
-------
Date: Thursday, 9 June 1983 16:18-EDT
From: MOON at SCRC-TENEX
To: Ron <FISCHER at RUTGERS>
Cc: common-lisp at SU-AI
Subject: Re: [Scott's message about EQ DEFCONSTANTs]
In-reply-to: The message of 9 Jun 83 14:17:40 EDT from Ron <FISCHER@RUTGERS.ARPA>
Date: 9 Jun 83 14:17:40 EDT
From: Ron <FISCHER@RUTGERS.ARPA>
DEFCONSTANT is defined in the manual to produce values that are EQUALP
only. Not EQ.
Not so. I assume you are referring to page 49 of the Laser edition. It
says nothing about any relation between the values of different instances
of open-coding of the variable by the compiler. What it does say is that
if you evaluate the form (DEFCONSTANT var val) twice, it is an error unless
the two values of val are EQUALP. But this misfeature has already been
removed by a previous ballot.
∂09-Jun-83 2101 Guy.Steele@CMU-CS-A New meaning for "Flag Day"
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 9 Jun 83 21:01:24 PDT
Date: 9 June 1983 2400-EDT (Thursday)
From: Guy.Steele@CMU-CS-A
To: common-lisp@SU-AI
Subject: New meaning for "Flag Day"
The Great Mail Blizzard of '83 seems to have subsided, and the outstanding
issues, nasty and otherwise, appear to be suitably dealt with. We have
to choose a cutoff date, and now seems to be a good time. I propose to
give yet another meaning to "Flag Day" (recall that, according to legend,
it was on June 14, 1966, that Multics converted from old ASCII to new ASCII).
If you have any outstanding problems or flames, please send those packets
in by 23:59 on June 14, 1983. After that point I propose to terminate
"elective" changes to the Common LISP manual. We will prepare a Dovered
limited edition much like the previous ones (Laser, Colander, and Swiss Cheese)
and send it out to all of you for the purpose of proofreading and
implementation, but seek feedback only on typographical errors, outright
errors or lies, and necessary improvements to the presentation. Technical
discussion will no doubt continue, but should be considered after Flag Day
as contributions toward the second edition or the Yellow Pages. I want
to proceed as expeditiously as possible to publication.
--Guy
∂10-Jun-83 1350 @MIT-MC:BSG%SCRC-TENEX%MIT-MC@SU-DSN Substitute-if
Received: from MIT-MC by SU-AI with TCP/SMTP; 10 Jun 83 13:50:25 PDT
Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Fri 10-Jun-83 16:10:10-EDT
Date: Friday, 10 June 1983, 16:10-EDT
From: Bernard S. Greenberg <BSG%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Substitute-if
To: Common-Lisp%su-ai%SCRC-TENEX%MIT-MC@SU-DSN
Before we cast the language in stone, I would like some resolution
of why substitute-if/nsubstitute-if have argument orders incongruous
with the rest of the if/if-not's.
∂10-Jun-83 1855 Guy.Steele@CMU-CS-A Re: Substitute-if
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 10 Jun 83 18:54:51 PDT
Date: 10 Jun 83 2153 EDT (Friday)
From: Guy.Steele@CMU-CS-A
To: Bernard S. Greenberg <BSG%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Re: Substitute-if
CC: common-lisp@SU-AI
In-Reply-To: "Bernard S. Greenberg's message of 10 Jun 83 15:10-EST"
I don't see that the argument order of substitute-if is incongruous.
Is your model that the TEST argument is alwaays the first one?
My model is that the xxx-if argument order is identical to the xxx
argument order except that the ITEM argument has been replaced
by the one-argument predicate TEST.
--Guy
∂10-Jun-83 1929 @MIT-MC:MOON@SCRC-TENEX Substitute-if
Received: from MIT-MC by SU-AI with TCP/SMTP; 10 Jun 83 19:29:12 PDT
Date: Friday, 10 June 1983 22:28-EDT
From: MOON at SCRC-TENEX
to: Common-Lisp at su-ai
Subject: Substitute-if
In-reply-to: The message of 10 Jun 1983 16:10-EDT from Bernard S. Greenberg <BSG%SCRC-TENEX%MIT-MC@SU-DSN>
Date: Friday, 10 June 1983, 16:10-EDT
From: Bernard S. Greenberg <BSG%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Substitute-if
To: Common-Lisp%su-ai%SCRC-TENEX%MIT-MC@SU-DSN
Before we cast the language in stone, I would like some resolution
of why substitute-if/nsubstitute-if have argument orders incongruous
with the rest of the if/if-not's.
I don't actually see what's incongruous about it. In the Laser edition,
all of the -if/-if-not functions replace the "item" argument with the
"test" argument; in other words replace the object being searched for
with the function to search for it. substitute-if doesn't have the
test as its first argument, but then substitute doesn't have the item
as its first argument either.
∂11-Jun-83 0527 FAHLMAN@CMU-CS-C DEFCONSTANT
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 11 Jun 83 05:27:13 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 11 Jun 83 08:27:36 EDT
Date: Sat, 11 Jun 1983 08:27 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Guy.Steele@CMU-CS-A
Cc: common-lisp@SU-AI
Subject: DEFCONSTANT
In-reply-to: Msg of 9 Jun 1983 0100-EDT () from Guy.Steele at CMU-CS-A
Guy,
If people want to stay with the EQ preserving version of DEFCONSTANT,
and not go to the macro-like definition, then maybe it would be good to
note this business about numbers not staying EQ in a note attached to
the DEFCONSTANT description. THat is one of the major places where this
will come up.
-- Scott
∂11-Jun-83 1118 David.Dill@CMU-CS-A EQ-preservation
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 11 Jun 83 11:17:53 PDT
Date: 11 June 1983 1416-EDT (Saturday)
From: David.Dill@CMU-CS-A (L170DD60)
To: common-lisp@su-ai
Subject: EQ-preservation
Message-Id: <11Jun83.141645.DD60@CMU-CS-A>
We have this excellent predicate EQL that I thought was invented for just
this purpose. DEFCONSTANT should be EQL-preserving.
Anyone who counts on numbers being EQ is likely to lose when implementations
have different thresholds of bignum-ness, or hacks like INUMs, anyway.
-Dave
∂11-Jun-83 1505 FAHLMAN@CMU-CS-C EQ-preservation
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 11 Jun 83 15:05:13 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 11 Jun 83 18:05:19 EDT
Date: Sat, 11 Jun 1983 18:05 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: David.Dill@λCMU-CS-A (L170DD60)λ
Cc: common-lisp@su-ai
Subject: EQ-preservation
In-reply-to: Msg of 11 Jun 1983 1416-EDT () from David.Dill at CMU-CS-A (L170DD60)
The question is not whether two distinct numbers are EQ, but whether
and in what conditions you can count on (EQ X X). If X has the
semantics of a variable reference, then you can count on this,
regardless of what is put in X. But if X could be expanded as a sort of
macro into a constant value each time it is seen, then maybe (EQ X X)
doesn't hold.
-- Scott
∂11-Jun-83 2048 David.Dill@CMU-CS-A EQness of numbers
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 11 Jun 83 20:47:59 PDT
Date: 11 June 1983 2309-EDT (Saturday)
From: David.Dill@CMU-CS-A (L170DD60)
To: common-lisp@su-ai
Subject: EQness of numbers
Message-Id: <11Jun83.230957.DD60@CMU-CS-A>
I seem to have yielded to a personal prejudice against using EQ in
common-lisp outside of implementation-level code (see flames of last
year). The issue of whether two numbers with the same value are always
EQ is indeed somewhat distinct from the issue of EQ preservation by
DEFCONSTANT.
Still, demanding EQL-equivalence but not EQ-equivalence provides the
maximum preservation of identity while not screwing compiler
optimizations. Using EQ on numbers (correctly) will probably be
a relatively rare operation, which is not worth sacrificing generally
applicable compiler optimizations for.
∂12-Jun-83 1151 @MIT-MC:MOON@SCRC-TENEX EQ-preservation
Received: from MIT-MC by SU-AI with TCP/SMTP; 12 Jun 83 11:51:32 PDT
Date: Sunday, 12 June 1983 14:47-EDT
From: MOON at SCRC-TENEX
To: Scott E. Fahlman <Fahlman at CMU-CS-C>
Cc: common-lisp at su-ai, l170dd60 at cmu-cs-a
Subject: EQ-preservation
In-reply-to: The message of Sat 11 Jun 1983 18:05 EDT from Scott E. Fahlman <Fahlman@CMU-CS-C>
Return-path: <Fahlman@CMU-CS-C>
Received: from MIT-MC by SCRC-TENEX with CHAOS; Sat 11-Jun-83 18:10:31-EDT
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 11 Jun 83 15:05:13 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 11 Jun 83 18:05:19 EDT
Date: Sat, 11 Jun 1983 18:05 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: David.Dill@λCMU-CS-A (L170DD60)λ
Cc: common-lisp@su-ai
Subject: EQ-preservation
In-reply-to: Msg of 11 Jun 1983 1416-EDT () from David.Dill at CMU-CS-A (L170DD60)
The question is not whether two distinct numbers are EQ, but whether
and in what conditions you can count on (EQ X X). If X has the
semantics of a variable reference, then you can count on this,
regardless of what is put in X.
Not so in Maclisp, as I understand it. And maybe not so on the LM-2
in a certain weird case involving an interrupt between the two references
to X (I forget whether or not it can happen). In both cases this only
happens when X is a number of course.
Does Common Lisp really undertake to guarantee (EQ X X) if the value of X
is a number? The writeup on EQ in the Laser edition could be interpreted
as either confirming or denying this.
On an unrelated note, did you notice that someone sabotaged your mail
header by putting backspaces into the "To Dill" line? I know I shouldn't
throw stones, the header of this message I'm sending now is going to have
a host you don't know about in it, because of Babyl.
∂12-Jun-83 1227 FAHLMAN@CMU-CS-C DEFCONSTANT and EQ
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 12 Jun 83 12:27:39 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 12 Jun 83 15:26:01 EDT
Date: Sun, 12 Jun 1983 15:25 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: common-lisp@su-ai
Subject: DEFCONSTANT and EQ
Well, nobody has expressed a strong opinion about the issue I raised, so
let me make a proposal for what should appear in the manual.
1. DEFCONSTANT does not create a "symbol macro". Conceptually, it
evaluates the init form at load time and sets the global special value
of the variable to that value. It also causes this symbol to be
CONSTANTP. The semantics of DEFCONSTANT differs from DEFVAR only in
that you must supply an init and you are declaring to the compiler that
the value of the variable will never be changed. The compiler can do
whatever it wants to with that information, but it must preserve the
variable-reference semantics. If the user violates this declaration, it
it "is an error" and might cause bad things to happen, but it might not
be signalled.
2. Numbers are particularly slippery items in Common Lisp. If you set X
to a number, it is not necessarily the case that (EQ X X), though you
can count on (EQL X X). This needs to be noted in the data type
chapter, and also should be referred to under EQ and maybe under
DEFCONSTANT.
3. I would like to include byte-specifiers in this slippery class as
well. Some implementations may choose to make these into numbers. In
any event, these are things that you especially want to do replacement
on.
4. Given the above rules, if X is a constant defined by DEFCONSTANT, the
compiler knows that it is safe to substitute the initial value V
(quoted) for references to X if V is a number of any kind, a byte
specifier, a symbol, or any kind of immediate object whose creation
involves no consing. A more complex compiler might be able to
substitute for other kinds of V if it can prove that the value is
consumed locally in a way that does not depend on EQ-ness, and that it
cannot escape the local environment to be EQ-tested elsewhere.
5. For now if you want the effect of symbol-macros, you have to do
something like
(defmacro x () '(a b c d e))
(print (x))
instead of
(defconstant x '(a b c d e))
(print x)
We may want to consider putting true symbol-macros into the next
edition, but let's not worry about this now. They are convenient, but
non-essential and somewhat confusing.
-- Scott
∂12-Jun-83 1306 ALAN@MIT-MC DEFCONSTANT and EQ
Received: from MIT-MC by SU-AI with TCP/SMTP; 12 Jun 83 13:06:27 PDT
Date: 12 June 1983 16:06 EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: DEFCONSTANT and EQ
To: Fahlman @ CMU-CS-C
cc: Common-Lisp @ SU-AI
In-reply-to: Msg of Sun 12 Jun 1983 15:25 EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: Sun, 12 Jun 1983 15:25 EDT
From: Scott E. Fahlman <Fahlman at CMU-CS-C>
3. I would like to include byte-specifiers in this slippery class as
well. Some implementations may choose to make these into numbers. In
any event, these are things that you especially want to do replacement
on.
Is it conceivable that, in some implementation, character objects would be
similarly slippery?
∂12-Jun-83 1317 FAHLMAN@CMU-CS-C DEFCONSTANT and EQ
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 12 Jun 83 13:17:33 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 12 Jun 83 16:15:48 EDT
Date: Sun, 12 Jun 1983 16:15 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Alan Bawden <ALAN@MIT-MC>
Cc: Common-Lisp@SU-AI
Subject: DEFCONSTANT and EQ
In-reply-to: Msg of 12 Jun 1983 16:06 EDT from Alan Bawden <ALAN at MIT-MC>
Well, I left those off the list because I assumed that they would be
immediate in essentially every implementation, so the question is moot.
However, this assumption might be unwarranted. We should probably say
that numbers, character objects, and byte specifiers are all slippery in
the same way.
By the way, I am not proposing "slippery" as a new technical term here.
No SLIPPERYP predicate. All I am saying is that the description of EQ
should contain a note that because of possible stack-allocation and
other optimizations, implementations should not depend on (EQ X X) if
the value of X is any kind of number, character object, or byte
specifier, even though this might work most of the time in most
implementations. They can depend on EQL.
-- Scott
∂12-Jun-83 1336 @MIT-MC:BSG%SCRC-TENEX%MIT-MC@SU-DSN Re: DEFCONSTANT and EQ
Received: from MIT-MC by SU-AI with TCP/SMTP; 12 Jun 83 13:36:20 PDT
Date: 12 Jun 1983 1631-EDT
From: Bernard S. Greenberg <BSG%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Re: DEFCONSTANT and EQ
To: Fahlman%CMU-CS-C@SU-DSN
cc: common-lisp@SU-AI
In-Reply-To: The message of Sun, 12 Jun 1983 15:25 EDT from Scott E. Fahlman <Fahlman@CMU-CS-C>
What about "strings"? Can the compiler fail to preserve eqness
of a defconstanted string?
-------
∂12-Jun-83 1346 @MIT-MC:MOON@SCRC-TENEX DEFCONSTANT and EQ
Received: from MIT-MC by SU-AI with TCP/SMTP; 12 Jun 83 13:46:34 PDT
Date: Sunday, 12 June 1983 16:45-EDT
From: MOON at SCRC-TENEX
To: Scott E. Fahlman <Fahlman at CMU-CS-C>
Cc: Alan Bawden <ALAN at MIT-MC>, Common-Lisp at SU-AI
Subject: DEFCONSTANT and EQ
In-reply-to: The message of Sun 12 Jun 1983 16:15 EDT from Scott E. Fahlman <Fahlman@CMU-CS-C>
Date: Sun, 12 Jun 1983 16:15 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
All I am saying is that the description of EQ
should contain a note that because of possible stack-allocation and
other optimizations, implementations should not depend on (EQ X X) if
the value of X is any kind of number, character object, or byte
specifier, even though this might work most of the time in most
implementations. They can depend on EQL.
EQL doesn't work on byte specifiers in your implementation, if I remember correctly.
∂12-Jun-83 1353 FAHLMAN@CMU-CS-C DEFCONSTANT and EQ
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 12 Jun 83 13:53:12 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 12 Jun 83 16:51:06 EDT
Date: Sun, 12 Jun 1983 16:51 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Common-Lisp@SU-AI
Subject: DEFCONSTANT and EQ
In-reply-to: Msg of 12 Jun 1983 16:45-EDT from MOON at SCRC-TENEX
Oops, true. You can still count on EQL for numbers and characters. You
probably should be able to count on EQUAL for byte specifiers, but not
EQL. Maybe all you can count on for these is that every time you pass X
to a function that takes byte-specifiers, it has the same effect.
-- Scott
∂12-Jun-83 1357 FAHLMAN@CMU-CS-C DEFCONSTANT and EQ
Received: from by SU-AI with PUP; 12-Jun-83 13:56 PDT
Received: From CMU-CS-C by SU-DSN.ARPA; Sun Jun 12 13:57:39 1983
Received: ID <FAHLMAN@CMU-CS-C>; 12 Jun 83 16:54:40 EDT
Date: Sun, 12 Jun 1983 16:54 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Bernard S. Greenberg <BSG%SCRC-TENEX@MIT-MC>
Cc: common-lisp%SU-AI@SU-DSN
Subject: DEFCONSTANT and EQ
In-reply-to: Msg of 12 Jun 1983 16:31-EDT from Bernard S. Greenberg <BSG%SCRC-TENEX at MIT-MC>
What about "strings"? Can the compiler fail to preserve eqness
of a defconstanted string?
I think the answer is NO, the compiler cannot do replacemnt of constant
strings in such a way as to destroy EQ-ness. If you allow this for
strings, you pretty much have to allow it for every sequence, including
lists, and we're back to symbol-macros again.
-- Scott
∂12-Jun-83 1406 FAHLMAN@CMU-CS-C DEFCONSTANT and EQ
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 12 Jun 83 14:06:12 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 12 Jun 83 17:04:05 EDT
Date: Sun, 12 Jun 1983 17:04 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Scott E. Fahlman <Fahlman@CMU-CS-C>
Cc: Common-Lisp@SU-AI
Subject: DEFCONSTANT and EQ
In-reply-to: Msg of 12 Jun 1983 16:51-EDT from Scott E. Fahlman <Fahlman>
On second thought, I would like to withdraw point 3 of my earlier
proposal, that byte-specifiers be slippery in the same sense that
numbers are. In all of the cases that matter, the compiler can easily
detect that the byte specifier is being consumed by the function that is
using it; in all other cases, we can just refer to the special value in
the usual EQ-preserving way. So we can get by with one less exceptional
case here.
Given this change, the only slippery objects are numbers (only the
consed ones) and character objects in implementations where those are
consed. These are precisely the objects that are treated differently by
EQ and EQL. So what Common Lisp really guarantees is that (EQL X X) but
not (EQ X X) in all cases.
-- Scott
∂12-Jun-83 1502 RZ@MIT-MC Rational and complex numbers
Received: from MIT-MC by SU-AI with TCP/SMTP; 12 Jun 83 15:01:32 PDT
Date: 12 June 1983 17:36 EDT
From: Richard E. Zippel <RZ @ MIT-MC>
Subject: Rational and complex numbers
To: common-lisp @ SU-AI
This message is not intended to change any of the decisions that have been
made in common lisp but to place into the record some comments on numbers
that I hope will prove useful next time. The thrust of these comments are
that the addition of these new data types to common lisp is premature---we
still don't understand the issues of coercion and type extension well enough
to define these particular types.
What are the types trying to represent?
One of the reasons that bignums are so important in Lisp that it allows us to
deal with a mathematically reasonable and well defined domain, namely the
rational integers as opposed to an ad hoc set of quantities: the bit
patterns that fit into a word.
In defining new data types for Lisp it should be clear what mathematical
domain we are trying to represent with the new type. Floating point numbers
are an attempt to represent the real numbers, but of course they are not a
particulary good representation. IEEE arithmetic, with gradual underflow is
better (quantities larger than the exponent range can be represented by
infinities, and small numbers gradually lose precision as they get closer to
0), but a bigfloat representation (with bignum exponents) provides an even
better model of the reals.
Common Lisp rational numbers are an attempt to model the quotient field of
the rational integers: Q. All elements of Q have distinct representations
as common lisp rational numbers which is good. Now what does 1 mean? Is it
an element of Z or Q? Here the problem is that we aren't sure, it depends
on what else it is combined with. We are trying to make 1 serve double duty
as multiplicative identity of both Z and Q, two very distinct rings. Of
course there are injections of Z into Q, and even a canonical one which we
can use when we accidentally combine an element of Z with one of Q, but
there cases when other injections are more appropriate. It seems more
natural to me, when writing programs, to make the coercion be more explicit.
This is somewhat reminescent of the problems we once had when namelists and
namestrings and pathnames could all be used interchangably.
Considering the complex types, mixed complex seems a little silly from this
point of view. Algebraically its not really a terribly interesting
structure. Either you are trying to represent the complex numbers (C) or
not. Mixing makes the internal coercions much more complicated and the
resulting mathematical structures has almost as many peculiarities as
fixnums. If you complexes are trying to represent C, then the two
components should represent R as well as possible, integers, rational
numbers and the like don't.
The gaussian number (complexes with integers coefficients) are interesting,
but why were they singled out? This is just one of a large number of
different algebraic extensions of the integers. Numbers of the form
a+b*sqrt(7) are just as useful as numbers of the form a+b*sqrt(-1). The
same holds for complexes with rational coefficients. Of course, higher
degree algebraic numbers are also reasonable candidates, as are polynomials
and rational functions, matrices ...
Fundamentally, my comment is that new data types have been introduced to
common lisp, and we don't yet have a good model of what they are trying to
represent and what the coercion mechanisms are to be between them.
For those who don't know me, I am one of the people who helped develop
Macsyma where we spent and are spending a great deal of time struggling with
these very issues.
∂12-Jun-83 1622 GSB@MIT-ML EQL and byte specifiers
Received: from MIT-ML by SU-AI with TCP/SMTP; 12 Jun 83 16:22:41 PDT
Date: 12 June 1983 19:22 EDT
From: Glenn S. Burke <GSB @ MIT-ML>
Subject: EQL and byte specifiers
To: MOON @ SCRC-TENEX
cc: Common-Lisp @ SU-AI, Fahlman @ CMU-CS-C, ALAN @ MIT-MC
EQL doesn't always work on them in NIL. (There are two formats.)
I could change this if necessary.
∂12-Jun-83 1656 @MIT-MC:MOON@SCRC-TENEX Rational and complex numbers
Received: from MIT-MC by SU-AI with TCP/SMTP; 12 Jun 83 16:56:24 PDT
Date: Sunday, 12 June 1983 19:54-EDT
From: MOON at SCRC-TENEX
To: Richard E. Zippel <RZ at MIT-MC>
Cc: common-lisp at SU-AI
Subject: Rational and complex numbers
In-reply-to: The message of 12 Jun 1983 17:36 EDT from Richard E. Zippel <RZ @ MIT-MC>
Is there really more than one reasonable injection of Z into Q?
∂12-Jun-83 1905 RZ@MIT-MC Rational and complex numbers
Received: from MIT-MC by SU-AI with TCP/SMTP; 12 Jun 83 19:05:36 PDT
Date: 12 June 1983 21:22 EDT
From: Richard E. Zippel <RZ @ MIT-MC>
Subject: Rational and complex numbers
To: MOON @ SCRC-TENEX
cc: common-lisp @ SU-AI
In-reply-to: Msg of 12 Jun 1983 19:54-EDT from MOON at SCRC-TENEX
Date: Sunday, 12 June 1983 19:54-EDT
From: MOON at SCRC-TENEX
To: Richard E. Zippel <RZ>
cc: common-lisp at SU-AI
Re: Rational and complex numbers
Is there really more than one reasonable injection of Z into Q?
Any map that sends 1 to an element of Q (other than 0) and all the elements
accordingly is reasonable. Basically, any time you are counting things by
halves, thirds, fourths or some other fraction you are presuming a different
injection. (otherwise known as scaling) It might be nice to be able to
have integers with these scaling factors built in. (multiples of pi or
pi/4 might be nice for trig calculations. Certainly radians would be a more
palatable measure of angles if the scaling factor of pi were built in.
acos(0) would be 1/2(radians). When converted to floating point (the reals)
it would of course give 1.57 ...) Why should these conversions be
any different from the standard one? (The answer is: because it is more
common)
I'm not suggesting that the natural coercion from Z to Q be thrown away as
much as suggesting that there is a lot more power and flexibility lurking
thee than w currently acknowledge.
∂12-Jun-83 1931 FAHLMAN@CMU-CS-C New built-in package
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 12 Jun 83 19:31:44 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 12 Jun 83 22:29:50 EDT
Date: Sun, 12 Jun 1983 22:29 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: moon%scrc-tenex@mit-mc
Cc: Common-Lisp@su-ai
Subject: New built-in package
In-reply-to: Msg of 12 Jun 1983 21:23-EDT from MOON at SCRC-TENEX
Date: Sunday, 12 June 1983 21:23-EDT
From: MOON at SCRC-TENEX
To: Common-Lisp-jokes <fahlman at cmuc>
Received: from MIT-MC by CMU-CS-C (with SMTP); 12 Jun 83 21:23:00 EDT
Well, that's what I get for listening to Fahlman! Keywords
now print out as "||:foo". Fixed momentarily...
I propose that henceforth all silly lisp code be interned in a package
named "(-". Symbols in this package would print as \(-:foo.
-- Scott
∂12-Jun-83 2053 Guy.Steele@CMU-CS-A Re: Rational and complex numbers
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 12 Jun 83 20:53:44 PDT
Date: 12 Jun 83 2346 EDT (Sunday)
From: Guy.Steele@CMU-CS-A
To: Richard E. Zippel <RZ@MIT-MC>
Subject: Re: Rational and complex numbers
CC: common-lisp@SU-AI
In-Reply-To: "Richard E. Zippel's message of 12 Jun 83 16:36-EST"
Your points are well-taken, and I'm glad they are in the record.
Originally, I suppose that the S-1 LISP implementation (of which I
one implementor) was the primary proponent of complex numbers in
Common LISP, out of a desire to be able to exploit the S-1 hardware
and yet also able to develop software in other implementations.
Hence the need for at least Cartesian complex floating-point data type.
I do foresee one entirely plausible application for Gaussian integers,
which is graphics applications. For discrete bit-map representations,
Gaussian integers may be a very convenient representation. Some interesting
work has been done at Yale on picture languages that use complex numbers.
I also admit once again to harboring the secret ambition for some form
of LISP to supplant FORTRAN...
--Guy
∂13-Jun-83 0629 @MIT-MC:BSG%SCRC-TENEX%MIT-MC@SU-DSN Substitute-if
Received: from MIT-MC by SU-AI with TCP/SMTP; 13 Jun 83 06:24:17 PDT
Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Mon 13-Jun-83 09:21:01-EDT
Date: Monday, 13 June 1983, 09:21-EDT
From: Bernard S. Greenberg <BSG%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Substitute-if
To: MOON%SCRC-TENEX%MIT-MC@SU-DSN, Common-Lisp@su-ai
In-reply-to: The message of 10 Jun 83 22:28-EDT from MOON at SCRC-TENEX
Date: Friday, 10 June 1983 22:28-EDT
From: MOON at SCRC-TENEX
Date: Friday, 10 June 1983, 16:10-EDT
From: Bernard S. Greenberg <BSG%SCRC-TENEX%MIT-MC@SU-DSN>
Before we cast the language in stone, I would like some resolution
of why substitute-if/nsubstitute-if have argument orders incongruous
with the rest of the if/if-not's.
I don't actually see what's incongruous about it. In the Laser edition,
all of the -if/-if-not functions replace the "item" argument with the
"test" argument; in other words replace the object being searched for
with the function to search for it. substitute-if doesn't have the
test as its first argument, but then substitute doesn't have the item
as its first argument either.
OK, I see the grand scheme here. My observation of inconsistency was based
upon the fact that substitute/nsubstitute/if/if-not do not have their
predicate argument first. I will modify my macrology appropriately.
∂14-Jun-83 0606 MLB@SPA-NIMBUS New built-in package Strikes Back.
Received: from by SU-AI with PUP; 14-Jun-83 06:06 PDT
Received: From MIT-XX by SU-DSN.ARPA; Tue Jun 14 06:07:13 1983
Date: Monday, 13 June 1983, 14:38-PDT
From: Marc LeBrun <MLB at SPA-Nimbus>
Subject: New built-in package Strikes Back.
To: Fahlman at CMU-CS-C
Cc: moon%scrc-tenex at mit-mc, Common-Lisp at su-ai
In-reply-to: The message of 12 Jun 83 19:29-PDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: Sun, 12 Jun 1983 22:29 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
Date: Sunday, 12 June 1983 21:23-EDT
From: MOON at SCRC-TENEX
Well, that's what I get for listening to Fahlman! Keywords
now print out as "||:foo". Fixed momentarily...
I propose that henceforth all silly lisp code be interned in a package
named "(-". Symbols in this package would print as \(-:foo.
-- Scott
The Common Lisp hack of making keywords evaluate to themselves is just an evil
idea whose only purpose is to save typing one character. The package name
string for keywords shouldn't be "" but "'". Keywords would look like ':foo
just as now. Old souces are compatible, and it has precedent in Steele's ASET'.
It creates some interesting issues for READ, but not insurmountable ones.
(Every time I want to see Benson turn green as Yoda I tell him this.)
∂14-Jun-83 1449 @USC-ECL,@MIT-XX:BSG@SCRC-TENEX Happy Flag Day
Received: from USC-ECL by SU-AI with TCP/SMTP; 14 Jun 83 14:49:18 PDT
Received: from MIT-XX by USC-ECL; Tue 14 Jun 83 14:47:41-PDT
Received: from SCRC-BEAGLE by SCRC-SPANIEL with CHAOS; Tue 14-Jun-83 15:33:31-EDT
Date: Tuesday, 14 June 1983, 15:33-EDT
From: Bernard S. Greenberg <BSG at SCRC-TENEX>
Subject: Happy Flag Day
To: Common-Lisp%SU-AI at USC-ECL
Re: Consistency of if/if-not's: I would like to quote the
following excerpts from the laser manual:
(p. 182)
SUBST new old tree &key :test :test-not :key
SUBST-IF predicate new tree &key :key
SUBST-IF-NOT predicate new tree &key :key
NSUBST new old tree &key :test :test-not :key
NSUBST-IF predicate new tree &key :key
NSUBST-IF-NOT predicate new tree &key :key
(p. 166)
SUBSTITUTE newitem olditem sequence &key :from-end ...
SUBSTITUTE-IF newitem test sequence &key ...
SUBSTITUTE-IF-NOT newitem test sequence &key ...
NSUBSTITUTE newitem olditem sequence &key :from-end ...
NSUBSTITUTE-IF newitem test sequence &key ...
NSUBSTITUTE-IF-NOT newitem test sequence &key ...
Either SUBSTITUTE-IF and his minions are consistent, as according to
Steele and Moon, because the predicate replaces the "old" argument, but
SUBST-IF and friends are inconsistent because of historical
considerations, OR SUBST-IF and friends are consistent with all of the
others (not shown here), because the predicate argument is first in all
of them, and SUBSTITUTE-IF and friends are inconsistent because they are
wrong.
∂14-Jun-83 2011 FAHLMAN@CMU-CS-C Happy Flag Day
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 14 Jun 83 20:11:08 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 14 Jun 83 23:10:55 EDT
Date: Tue, 14 Jun 1983 23:10 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Bernard S. Greenberg <BSG%SCRC-TENEX@mit-mc>
Cc: Common-Lisp@su-ai
Subject: Happy Flag Day
In-reply-to: Msg of 14 Jun 1983 15:33-EDT from Bernard S. Greenberg <BSG at SCRC-TENEX>
Well, BSG may get the prize for the last change to go in. I'm not
completely sure whether the SUBST or SUBSTITUTE format is right, but we
can't leave them inconsistent. Looks to me like SUBST and friends need
to change.
-- Scott
∂14-Jun-83 2027 KMP@MIT-MC
Received: from MIT-MC by SU-AI with TCP/SMTP; 14 Jun 83 20:26:53 PDT
Date: 14 June 1983 23:26 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
To: Fahlman @ CMU-CS-C
cc: Common-Lisp @ SU-AI
If by "SUBST and friends" you mean "SUBST's friends", I am amenable.
I agree the current setup is not going to help users remember things easily
and am in favor of making them either all "new old/pred tree/seq" or
"new old tree/seq"/"pred new tree/seq", with a slight bias for the former
because I think the argument of program flexibility in its favor slightly
outweighs the argument of pronouncibility.
∂14-Jun-83 2054 @MIT-MC:BSG%SCRC-TENEX%MIT-MC@SU-DSN Re: Happy Flag Day
Received: from MIT-MC by SU-AI with TCP/SMTP; 14 Jun 83 20:54:36 PDT
Date: 14 Jun 1983 2336-EDT
From: Bernard S. Greenberg <BSG%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Re: Happy Flag Day
To: Fahlman%CMU-CS-C@SU-DSN
cc: BSG%SCRC-TENEX%MIT-MC@SU-DSN, Common-Lisp@SU-AI
In-Reply-To: The message of Tue, 14 Jun 1983 23:10 EDT from Scott E. Fahlman <Fahlman@CMU-CS-C>
Return-path: <Fahlman@CMU-CS-C>
Received: from MIT-MC by SCRC-TENEX with CHAOS; Tue 14-Jun-83 23:12:18-EDT
Received: ID <FAHLMAN@CMU-CS-C>; 14 Jun 83 23:10:55 EDT
Date: Tue, 14 Jun 1983 23:10 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Bernard S. Greenberg <BSG%SCRC-TENEX@mit-mc>
Cc: Common-Lisp@su-ai
Subject: Happy Flag Day
In-reply-to: Msg of 14 Jun 1983 15:33-EDT from Bernard S. Greenberg <BSG at SCRC-TENEX>
Well, BSG may get the prize for the last change to go in. I'm not
completely sure whether the SUBST or SUBSTITUTE format is right, but we
can't leave them inconsistent. Looks to me like SUBST and friends need
to change.
-- Scott
-----
Leave SUBST (historical reasons) and fix SUBSTITUTE &c. Make my
macros much happier, and makes for a simpler rule:predicate
arg is always FIRST.
-------
∂14-Jun-83 2106 Guy.Steele@CMU-CS-A BONG BONG BONG BONG BONG BONG BONG BONG BONG BONG BONG BONG
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 14 Jun 83 21:06:29 PDT
Date: 15 Jun 83 0001 EDT (Wednesday)
From: Guy.Steele@CMU-CS-A
To: common-lisp@SU-AI
Subject: BONG BONG BONG BONG BONG BONG BONG BONG BONG BONG BONG BONG
The window for technical changes to the First Edition of the Common LISP
Manual has been *closed*. Reports of typographical errors and inconsistencies
will still be gratefully welcomed. Continued technical discussion will
be accumulated toward the second addition. Thanks to everyone for their
efforts!
--Guy
∂14-Jun-83 2107 Guy.Steele@CMU-CS-A Darn!
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 14 Jun 83 21:07:08 PDT
Date: 15 Jun 83 0002 EDT (Wednesday)
From: Guy.Steele@CMU-CS-A
To: common-lisp@SU-AI
Subject: Darn!
"addition" => "edition". I was typing so fast I blew it, and still
didn't get the message out until 00:01. Sigh.
--Guy
∂15-Jun-83 0530 @MIT-ML:BSG%SCRC-TENEX%MIT-ML@SU-DSN Re: Happy Flag Day
Received: from MIT-ML by SU-AI with TCP/SMTP; 15 Jun 83 05:30:04 PDT
Date: 15 Jun 1983 0749-EDT
From: Bernard S. Greenberg <BSG%SCRC-TENEX%MIT-ML@SU-DSN>
Subject: Re: Happy Flag Day
To: Moon%SCRC-TENEX%MIT-ML@SU-DSN
cc: Common-Lisp@SU-AI
In-Reply-To: The message of Wednesday, 15 June 1983, 02:21-EDT from David A. Moon <Moon at SCRC>
Return-path: <Moon@SCRC-TENEX>
Received: from SCRC-SPANIEL by SCRC-TENEX with CHAOS; Wed 15-Jun-83 02:22:19-EDT
Received: from SCRC-EUPHRATES by SCRC-SPANIEL with CHAOS; Wed 15-Jun-83 02:21:52-EDT
Date: Wednesday, 15 June 1983, 02:21-EDT
From: David A. Moon <Moon at SCRC>
Subject: Re: Happy Flag Day
To: Bernard S. Greenberg <BSG at SCRC>
Cc: Common-Lisp at SU-AI
In-reply-to: The message of 14 Jun 83 23:36-EDT from Bernard S. Greenberg <BSG%SCRC-TENEX%MIT-MC at SU-DSN>
Date: 14 Jun 1983 2336-EDT
From: Bernard S. Greenberg <BSG%SCRC-TENEX%MIT-MC@SU-DSN>
Leave SUBST (historical reasons) and fix SUBSTITUTE &c.
But (p. 182)
SUBST new old tree &key :test :test-not :key
SUBST-IF predicate new tree &key :key
So historical reasons make no sense. No one proposes to make
the args to SUBST be old first then new.
I can live with whichever Guy decides to change (SUBST-IF or
SUBSTITUTE-IF) as long as he makes them consistent.
----------
OK, I believe this.
-------
∂15-Jun-83 0934 HEDRICK@RUTGERS.ARPA consistency
Received: from RUTGERS by SU-AI with TCP/SMTP; 15 Jun 83 09:34:26 PDT
Date: 15 Jun 83 12:14:08 EDT
From: Dir LCSR Comp Facility <HEDRICK@RUTGERS.ARPA>
Subject: consistency
To: common-lisp@SU-AI.ARPA
This is a general comment, not aimed at any specific message, but at
a number that I have seen. If we try to make all of Common Lisp
consistent in argument order and everything else, we are going to
be here for years. In my opinion it is more important to keep it
consistent with other dialects of Lisp. This is not supposed to
be a new language. It originally started out to be a common subset
of the various Maclisp dialects. Personally I wish it had stayed
as that, but that is obviously impossible. However I would at least
like it to continue to be a dialect of Lisp. This means that people
who have studied a standard textbook in Lisp should be able to use it
without finding that all of the functions have been renamed for
"consistency", argument orders have been changed, etc. Of course
we can always put back traditional functions that you have left out,
but it is much harder for us to change back to traditional argument
orders.
-------
∂15-Jun-83 0938 Moon@SCRC-TENEX Re: Happy Flag Day
Received: from SU-DSN by SU-AI with PUP; 15-Jun-83 09:37 PDT
Received: From MIT-XX by SU-DSN.ARPA; Wed Jun 15 09:38:49 1983
Received: from SCRC-EUPHRATES by SCRC-SPANIEL with CHAOS; Wed 15-Jun-83 02:21:52-EDT
Date: Wednesday, 15 June 1983, 02:21-EDT
From: David A. Moon <Moon at SCRC>
Subject: Re: Happy Flag Day
To: Bernard S. Greenberg <BSG at SCRC>
Cc: Common-Lisp at SU-AI
In-reply-to: The message of 14 Jun 83 23:36-EDT from Bernard S. Greenberg <BSG%SCRC-TENEX%MIT-MC at SU-DSN>
Date: 14 Jun 1983 2336-EDT
From: Bernard S. Greenberg <BSG%SCRC-TENEX%MIT-MC@SU-DSN>
Leave SUBST (historical reasons) and fix SUBSTITUTE &c.
But (p. 182)
SUBST new old tree &key :test :test-not :key
SUBST-IF predicate new tree &key :key
So historical reasons make no sense. No one proposes to make
the args to SUBST be old first then new.
I can live with whichever Guy decides to change (SUBST-IF or
SUBSTITUTE-IF) as long as he makes them consistent.
∂15-Jun-83 0937 Moon@SCRC-TENEX DEFCONSTANT and EQ
Received: from SU-DSN by SU-AI with PUP; 15-Jun-83 09:37 PDT
Received: From MIT-XX by SU-DSN.ARPA; Wed Jun 15 09:37:11 1983
Received: from SCRC-EUPHRATES by SCRC-SPANIEL with CHAOS; Wed 15-Jun-83 00:47:06-EDT
Date: Wednesday, 15 June 1983, 00:44-EDT
From: David A. Moon <Moon at SCRC-TENEX>
Subject: DEFCONSTANT and EQ
To: common-lisp at su-ai
In-reply-to: The message of 12 Jun 83 15:25-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>,
The message of 8 Jun 83 16:19-EDT from Bernard S. Greenberg <BSG%SCRC-TENEX at MIT-MC>,
The message of 8 Jun 83 21:11-EDT from Glenn S. Burke <GSB at MIT-ML>,
The message of 8 Jun 83 14:46-EDT from Bernard S. Greenberg <BSG%SCRC-TENEX%MIT-MC at SU-DSN>,
The message of 8 Jun 83 14:11-EDT from Bernard S. Greenberg <BSG%SCRC-TENEX%MIT-MC at SU-DSN>,
The message of 8 Jun 83 09:55-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>,
The message of 8 Jun 83 01:46-EDT from Guy.Steele at CMU-CS-A,
The message of 8 Jun 83 01:40-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>,
The message of 8 Jun 83 02:47-EDT from Kent M. Pitman <KMP at MIT-MC>,
The message of 7 Jun 83 22:16-EDT from David A. Moon <Moon%SCRC-TENEX%MIT-MC at SU-DSN>
Date: 8 June 1983 0146-EDT (Wednesday)
From: Guy.Steele@CMU-CS-A
The initial-value form to DEFCONSTANT is conceptually evaluated at load
time. DEFCONSTANT is an invitation to the compiler to susbtitute the
value for occurrences of the constant *if* the compiler is smart enough
to do so. DEFCONSTANT is not meant to side-effect the compiler's environment.
(DEFCONSTANT FOO 3)
(DEFCONSTANT BAR (+ FOO 6))
entitles the compiler to use the value 9 for BAR provided that it is
smart enough to analyze what it going on (actually notall that hard:
the first declaration entitles the compiler to substitute 3 for FOO,
whereupon some simple constant folding reduces (+ 3 6) to 9).
Date: Sun, 12 Jun 1983 15:25 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
1. DEFCONSTANT does not create a "symbol macro". Conceptually, it
evaluates the init form at load time and sets the global special value
of the variable to that value. It also causes this symbol to be
CONSTANTP. The semantics of DEFCONSTANT differs from DEFVAR only in
that you must supply an init and you are declaring to the compiler that
the value of the variable will never be changed. The compiler can do
whatever it wants to with that information, but it must preserve the
variable-reference semantics. If the user violates this declaration, it
it "is an error" and might cause bad things to happen, but it might not
be signalled.
4. Given the above rules, if X is a constant defined by DEFCONSTANT, the
compiler knows that it is safe to substitute the initial value V
(quoted) for references to X if V is a number of any kind,
a symbol, or any kind of immediate object whose creation
involves no consing. A more complex compiler might be able to
substitute for other kinds of V if it can prove that the value is
consumed locally in a way that does not depend on EQ-ness, and that it
cannot escape the local environment to be EQ-tested elsewhere.
I agree with this. An example of your last sentence would be the byte-specifier
argument to LDB.
Date: Wednesday, 8 June 1983, 16:19-EDT
From: Bernard S. Greenberg <BSG%SCRC-TENEX@MIT-MC>
The loading of a DEFCONSTANT changes the symbol being defined
in a (so far) unalterable fashion. There ought to be an
in-language way to revoke this effect.
This is important. UNDEFCONSTANT is a reasonable name.
Date: 8 June 1983 21:11 EDT
From: Glenn S. Burke <GSB @ MIT-ML>
The one thing which needs to be clearly specified is how the semantics
of "added to the compilation environment" differs from what might be
done by (eval-when (compile) ...). If, for instance, defmacro does
not bash the runtime environment, then the user will have to use
eval-when if the macro needs to be usable via the interpreter during
the compilation. Eval-when should do exactly that: evaluate and bash
the runtime environment. Always, without exception, no matter what
"added to the compilation environment" might mean. My own experience
is that it is generally a loss for "added to the compilation
environment" to bash the runtime environment.
I agree with this. (eval-when (compile ...) form) should eval form, no
ifs, ands, or buts. Forms seen by the compiler and not inside an
eval-when-compile should not affect the run-time environment, to the
extent that is possible (it is unlikely to be possible for the package
declaration forms). The manual should clearly document which forms
affect the environment in which the compiler (and the user's macros)
are running when seen by the compiler.
Note that, contrary to several people's mail, packages are no help
in keeping the run-time and compile-time environments straight, any
time you are compiling a program that you also run in the compiler.
Even in a system where the compiler is run in a separate Lisp, there
is an issue when compiling a system of macros, for example, since it
has to run in the compiler as well as being compiled.
Getting back to DEFCONSTANT, evaluation of its initial-value subform
should not affect the run-time environment -- the compiler should
analyze the initial value, not EVAL it. Furthermore the value of
the symbol should not change in the compiler's environment; the
compiler should remember the constant value someplace else. Only
when the DEFCONSTANT is actually loaded should the value of the
symbol be changed.
Later we might want to standardize some tools for getting at the
compile-time environment. For instance, a macro running in the
compiler can use CONSTANTP to determine that a symbol has been
declared to be a DEFCONSTANT, and hence that its value won't change
no matter what code is executed between two successive references
[this is the sort of thing SETF needs to know, for example].
However the current language provides no way for that macro to
find out what the actual value of the DEFCONSTANT is. And of
course, given the above definition the compiler may not even -know-
what the actual value of the DEFCONSTANT is going to be. Pathologically,
(DEFCONSTANT FUBAR (MACHINE-INSTANCE))
(DEFCONSTANT SPAM (FUNCTION-HALTS-P 'BAZ))
Date: Wednesday, 8 June 1983, 14:46-EDT
From: Bernard S. Greenberg <BSG%SCRC-TENEX%MIT-MC@SU-DSN>
The answer to "What kind of evaluator or meta-
evaluator should be invoked on the second operand of DEFCONSTANT?" is
"the compiler's pass-1 optimizer/reducer"! That is not something we
do now, but there is no good reason why not.
Actually we do do this in our "DEFSYSCONSTANT" stuff (which is
associated with the Lisp cold-load generator, declaring constants that
will be constant in the Lisp system being built.) But we don't do it
yet in our Common Lisp DEFCONSTANT implementation.
Date: 8 June 1983 02:47 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
I am still bothered that on the LispM, the compiler does a
side-effect to my compile-time environment when it sees DEFSETF,
for example.
Indeed, this is wrong, and some day we have to get our act together and
fix this kind of thing. It means that DEFSETF and SETF have to have
explicit knowledge of the two separate environments, unless you don't
want merely compiling a DEFSETF (without loading it) to affect the
subsequent expansion of SETF in the same compilation.
∂16-Jun-83 0946 RPG consistency
∂15-Jun-83 0934 HEDRICK@RUTGERS.ARPA consistency
Received: from RUTGERS by SU-AI with TCP/SMTP; 15 Jun 83 09:34:26 PDT
Date: 15 Jun 83 12:14:08 EDT
From: Dir LCSR Comp Facility <HEDRICK@RUTGERS.ARPA>
Subject: consistency
To: common-lisp@SU-AI.ARPA
This is a general comment, not aimed at any specific message, but at
a number that I have seen. If we try to make all of Common Lisp
consistent in argument order and everything else, we are going to
be here for years. In my opinion it is more important to keep it
consistent with other dialects of Lisp. This is not supposed to
be a new language. It originally started out to be a common subset
of the various Maclisp dialects. Personally I wish it had stayed
as that, but that is obviously impossible. However I would at least
like it to continue to be a dialect of Lisp. This means that people
who have studied a standard textbook in Lisp should be able to use it
without finding that all of the functions have been renamed for
"consistency", argument orders have been changed, etc. Of course
we can always put back traditional functions that you have left out,
but it is much harder for us to change back to traditional argument
orders.
-------
Common Lisp Ontology
Chuck:
As one of the first people to discuss Common Lisp (along with Guy Steele,
JonL White, Scott Fahlman, and Bill Scherlis [a colleague of mine]), I can
report that we never discussed a ``common subset of the various Maclisp
dialects'' per se. My recollection is that we recognized that the existing
dialects were close together and that, therefore, it was silly to have 4 or
5 dialects that were slightly different from each other.
We then tried to unify these dialects, creating a common core language.
We began small and, due to influence from various sources, were convinced
that many features were better done by the implementors than by users.
Thus we created the language of which our various implementations
would be supersets. Quite a different thing.
In some way I'm sorry that I was wedded to the S-1 when I was helping with
the design of the Common Lisp since the power and size of that machine
blinded me to the needs of `lesser' machines, such as the Vax and 68000.
ARPA now thinks that Common Lisp will run on all machines and is spending
some money in that direction. I doubt that an 8mhz 68000 is ever going to
run full Common Lisp well.
The point about ARPA is critical. Though we `strived' to make Common Lisp
compatible with Maclisp, Lisp Machine Lisp, and InterLisp (in that order),
I think that if Common Lisp succeeds, it will succeed precisely because it
won't matter that it is compatible. It will succeed because people will use
it (or be required to use it) in place of other Lisps. The fact that it
is compatible with MacLisp will be a curious fact, a way to describe Common
Lisp (``It's like Maclisp, only bigger''), but not crucial.
As you know, there is no good, standard textbook on Lisp. The first one
has yet to be written, and perhaps it will use Common Lisp as its
language. [Rod Brooks, Bill Scherlis, and I are beginning to write an
advanced textbook on Lisp programming style, and we are using Common Lisp
as our language. This will not be the standard textbook since it will
cover advanced techniques, but other books may be written to serve as its
foundation.]
-rpg-
∂16-Jun-83 0946 RPG DEFSETF
∂15-Jun-83 0936 Moon@SCRC-TENEX DEFSETF
Received: from SU-DSN by SU-AI with PUP; 15-Jun-83 09:35 PDT
Received: From MIT-XX by SU-DSN.ARPA; Wed Jun 15 09:36:26 1983
Received: from SCRC-EUPHRATES by SCRC-SPANIEL with CHAOS; Wed 15-Jun-83 00:22:06-EDT
Date: Wednesday, 15 June 1983, 00:19-EDT
From: David A. Moon <Moon at SCRC-TENEX>
Subject: DEFSETF
To: STEELE at CMU-CS-C
Cc: fahlman at CMU-CS-C, dlw at SCRC-TENEX, rpg at SU-AI
In-reply-to: The message of 13 Jun 83 00:25-EDT from STEELE at CMU-CS-C
Date: 13 Jun 83 00:25:58 EDT
From: STEELE@CMU-CS-C
Maybe DEFINE-MODIFY-MACRO doesn't want to deal with &KEY, but I am
pretty sure that DEFSETF in the complex form *does* want to deal
with &KEY? In particular, you might well want to use different
expansions depending on whether a particular keyword argument is
supplied or not.
This is somewhat reasonable. Note that it isn't trivial; someone (I no longer
have that message) said that it can just use DEFMACRO's &KEY binding
facility. But this isn't true, because the code generated by DEFSETF has to
create the temporary variables and forms whose values they are bound to
(the first two parts of the setf-method). It could have one
temporary variable for each &key variable, in which case the keywords
have to be constant at macro-expansion time (which you seem to have
tacitly assumed above), and code has to be generated to give an explanatory
message if they aren't constant. Or else it could bind one temporary
variable to a list of the keyword part of the form, but then that list
would actually be consed up at run time, which is presumably not what
you want.
If you are going to use different expansions depending on whether
a particular keyword argument is supplied or not, then you may not
want to bind a temporary variable to the value of the keyword argument
at all, because it's only going to be looked-at at macro-expansion
time, not at run time. In this case you should be DEFINE-SETF-METHOD
rather than the complex form of DEFSETF, i.e. you don't want the setf
system to second-guess you on which temporary variables are desired.
Given the above considerations, I think the complex form of DEFSETF
should be restricted to &REST, and only DEFINE-SETF-METHOD (the
hypercomplex form of DEFSETF) should be allowed to use &KEY. This also
takes no implementation effort since DEFINE-SETF-METHOD does its
argument processing exactly the same way as DEFMACRO.
Hmm, well it's 18 minutes after Flag Day ends, hopefully this can
count as a clarification.
∂16-Jun-83 0947 RPG Package chapter updated
∂07-Jun-83 2154 FAHLMAN@CMU-CS-C Package chapter updated
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 7 Jun 83 21:54:31 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 8 Jun 83 00:54:06 EDT
Date: Wed, 8 Jun 1983 00:54 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: steele@CMU-CS-C
Cc: moon%scrc-tenex@mit-mc, dlw%scrc-tenex@mit-mc, rpg@su-ai,
les@CMU-CS-C
Subject: Package chapter updated
<fahlman.clm>package.mss now contains a version of the package chapter
that is updated to reflect the recent decisions:
Package names (and module names) are now read by rules identical to
those for symbols and are match in a case-sensitive manner. All
functions that take package or module names now accept either a string
or a symbol. The usual case will be to use the symbol and not worry
about capitalization. The examples now show this.
INTERN and FIND-SYMBOL now return the values suggested by MOON.
FIND-EXTERNAL-SYMBOL sleeps with the fishes.
I have reinstalled RENAME-PACKAGE, which somehow disappeared in all the
editing that went on.
There may, of course, be some inconsistencies that I have overlooked.
I'm sure that these will be caught in proof-reading, if not sooner --
I've read all this so many times I can't see it any more.
∂16-Jun-83 0949 RPG Package chapter updated
∂07-Jun-83 2154 FAHLMAN@CMU-CS-C Package chapter updated
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 7 Jun 83 21:54:31 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 8 Jun 83 00:54:06 EDT
Date: Wed, 8 Jun 1983 00:54 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: steele@CMU-CS-C
Cc: moon%scrc-tenex@mit-mc, dlw%scrc-tenex@mit-mc, rpg@su-ai,
les@CMU-CS-C
Subject: Package chapter updated
<fahlman.clm>package.mss now contains a version of the package chapter
that is updated to reflect the recent decisions:
Package names (and module names) are now read by rules identical to
those for symbols and are match in a case-sensitive manner. All
functions that take package or module names now accept either a string
or a symbol. The usual case will be to use the symbol and not worry
about capitalization. The examples now show this.
INTERN and FIND-SYMBOL now return the values suggested by MOON.
FIND-EXTERNAL-SYMBOL sleeps with the fishes.
I have reinstalled RENAME-PACKAGE, which somehow disappeared in all the
editing that went on.
There may, of course, be some inconsistencies that I have overlooked.
I'm sure that these will be caught in proof-reading, if not sooner --
I've read all this so many times I can't see it any more.
∂16-Jun-83 1119 Cassels@SCRC-TENEX floating-point format
Received: from SU-DSN by SU-AI with PUP; 16-Jun-83 11:18 PDT
Received: From MIT-XX by SU-DSN.ARPA; Thu Jun 16 11:01:04 1983
Received: from SCRC-MENOTOMY by SCRC-SPANIEL with CHAOS; Thu 16-Jun-83 12:13:32-EDT
Date: Thursday, 16 June 1983, 12:13-EDT
From: Robert A. Cassels <Cassels at SCRC-TENEX>
Subject: floating-point format
To: Moon at SCRC-TENEX, Common-Lisp at SU-AI
In-reply-to: The message of 31 May 83 23:41-EDT from David A. Moon <Moon%SCRC-TENEX%MIT-MC at SU-DSN>
Date: Tuesday, 31 May 1983, 23:41-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
...
16. Guy proposes the following treatment of floating point in FORMAT:
~w,d,pF
~w,d,x,pE
~w,d,pG
The meanings of the arguments are exactly as for the FORTRAN-77
language as described in chapter 13 of the FORTRAN-77 standard,
with the following exceptions and extensions:
...
From ANSI X3.9 1978 (selected highlights from chapter 13)
F editing: Optional blanks, optional sign, and a string of digits that
contains a decimal point, rounded to d fractional digits. Leading zeros
are not permitted except for an optional zero immediately to the left of
the decimal point if the magnitude is less than one. The optional zero
must appear if there would otherwise be no digits in the output field.
[It says nothing about trailing zeros.]
I guess we need to be specific about rounding. The spirit of Fortran,
if not the letter, is that all digits printed are rounded in decimal.
(Specified for F-format, but not for E-format.)
Fortran rounding on ties is away from zero. (2.5 => 3, -2.5 => -3)
IEEE says that binary-decimal conversions must respect the rounding
mode, and the default rounding mode rounds to even on ties.
Do we want to require that all digits printed be decimal-rounded for all
formats? [I think so.]
What rounding happens on ties? [I don't care -- either Fortran rounding
or round-to-nearest-even is acceptable.]
∂16-Jun-83 1132 @MIT-MC:MOON@SCRC-TENEX floating-point format
Received: from MIT-MC by SU-AI with TCP/SMTP; 16 Jun 83 11:32:27 PDT
Date: Thursday, 16 June 1983 13:58-EDT
From: MOON at SCRC-TENEX
To: Robert A. Cassels <Cassels at SCRC-TENEX>
Cc: Common-Lisp at SU-AI
Subject: floating-point format
In-reply-to: The message of 16 Jun 1983 12:13-EDT from Robert A. Cassels <Cassels at SCRC-TENEX>
Decimal rounding of the digits printed, and tie-breaking according to
system-dependent standards (IEEE for us) sounds reasonable to me.
∂16-Jun-83 1402 @MIT-MC:kmp@MIT-MC Rounding on output
Received: from MIT-MC by SU-AI with TCP/SMTP; 16 Jun 83 14:02:15 PDT
Date: Thursday, 16 June 1983, 17:02-EDT
From: Kent M. Pitman <kmp at MIT-MC>
Subject: Rounding on output
To: Common-Lisp at SAIL
With one exception, I have no special opinions about rounding on output
and will take whatever is given. The exception is that the rounding
should be defined to always produce a valid number, even if in some cases
that means violating the normal rounding rule once in a while. In Maclisp,
the largest flonum (octal 377777,,777777) can be typed in by 1.70141182e+38
but will type out as 1.70141183e+38, which cannot be re-read because it gives
a numeric overflow error. I can't decide if this is relevant to ~G, etc. or
just to general PRIN1, but figured this was as good a time as any to mention
it...
∂16-Jun-83 1551 @MIT-MC:Cassels%SCRC-TENEX%MIT-MC@SU-DSN Rounding on output
Received: from MIT-MC by SU-AI with TCP/SMTP; 16 Jun 83 15:50:25 PDT
Received: from SCRC-MENOTOMY by SCRC-TENEX with CHAOS; Thu 16-Jun-83 18:49:50-EDT
Date: Thursday, 16 June 1983, 18:47-EDT
From: Robert A. Cassels <Cassels%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Rounding on output
To: kmp%MIT-MC@SU-DSN, Common-Lisp@SU-AI
In-reply-to: The message of 16 Jun 83 17:02-EDT from Kent M. Pitman <kmp at MIT-MC>
Date: Thursday, 16 June 1983, 17:02-EDT
From: Kent M. Pitman <kmp at MIT-MC>
With one exception, I have no special opinions about rounding on output
and will take whatever is given. The exception is that the rounding
should be defined to always produce a valid number, even if in some cases
that means violating the normal rounding rule once in a while. In Maclisp,
the largest flonum (octal 377777,,777777) can be typed in by 1.70141182e+38
but will type out as 1.70141183e+38, which cannot be re-read because it gives
a numeric overflow error. I can't decide if this is relevant to ~G, etc. or
just to general PRIN1, but figured this was as good a time as any to mention
it...
This problem is only vaguely related to "rounding". The real thing you
are asking for (which is not true of most reader/printer pairs) is that
the (read (print .)) be an identity. Most readers and printers are
sloppy about that, especially for exponents of large magnitude. The
current Lisp Machine reader is very sloppy.
I think that the "valid number" requirement is in fact wrong. If I ask
for your largest flonum to be printed to only one decimal place, I would
certainly like to see 2.e+38, even though that is not a valid number.
But invalid numbers should only occur when I specify the length of the
printed result.
So the correct wording of your requirement is something like:
"The (binary) floating-point value read shall be closer to the decimal
value than any other floating-point value of the same length."
"The decimal value printed shall be closer to the (binary)
floating-point value than it is to any other representable
floating-point value of the same length." [Although that doesn't
exactly rule out printing decimal values beyond the range of floats, I
don't see how to word it without getting into ULPs (units in the last
place) or other nasty stuff. Guy??]
∂16-Jun-83 1604 RPG Common Lisp Ontology
∂16-Jun-83 1453 @MIT-MC:DLW%SCRC-TENEX%MIT-MC@SU-DSN Common Lisp Ontology
Received: from MIT-MC by SU-AI with TCP/SMTP; 16 Jun 83 14:52:08 PDT
Received: from SCRC-BORZOI by SCRC-TENEX with CHAOS; Thu 16-Jun-83 17:53:45-EDT
Date: Thursday, 16 June 1983, 17:51-EDT
From: Daniel L. Weinreb <DLW%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Common Lisp Ontology
To: RPG@SU-AI
In-reply-to: The message of 16 Jun 83 12:44-EDT from Dick Gabriel <RPG at SU-AI>
Actually, "Maclisp compatibility" was never a true goal; we all agreed
from day 1 about changing / to \, for example.
If you don't know about Dave Touretsky's new introductory Lisp book, you
should ask someone about it. I was sent a copy for review from Harper &
Row; I liked it a lot. I don't know what its current state is. As you
probably know, Dave is from CMU. I said in my review that it should use
Common Lisp or be as close as possible. I don't know if it's getting
published or what.
∂16-Jun-83 1759 FAHLMAN@CMU-CS-C Rounding on output
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 16 Jun 83 17:59:32 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 16 Jun 83 20:59:02 EDT
Date: Thu, 16 Jun 1983 20:59 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Robert A. Cassels <Cassels%SCRC-TENEX%MIT-MC@SU-DSN>
Cc: Common-Lisp@SU-AI
Subject: Rounding on output
In-reply-to: Msg of 16 Jun 1983 18:47-EDT from Robert A. Cassels <Cassels%SCRC-TENEX%MIT-MC at SU-DSN>
Do we really have to lay down complicated rules for rounding of printed
flonums in the white pages? I can't believe that all of these marginal
cases matter. Why don't we just say that the results are supposed to be
rounded appropriately and let the implementors worry about overflow
conditions and how to break ties and what is done with the last bit.
I am aware that rounding is a very serious matter in floating-point
arithmetic, since if it is not done right the insignificant roundoff
errors can accumulate and drop your space shuttle into the middle of
Manhattan. But I don't think that such considerations apply in printed
flonums, since it is hard for any substantial error to accumulate in a
small number of print/read cycles.
-- Scott
∂16-Jun-83 2047 Guy.Steele@CMU-CS-A Re: Rounding on output
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 16 Jun 83 20:46:53 PDT
Date: 16 Jun 83 2344 EDT (Thursday)
From: Guy.Steele@CMU-CS-A
To: Robert A. Cassels <Cassels%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Re: Rounding on output
CC: common-lisp@SU-AI
In-Reply-To: "Robert A. Cassels's message of 16 Jun 83 17:47-EST"
I agree with your clarified text on ideal floating-point I/O.
For the last eight months I have been one month away from completing
a paper containing what I claim, with proofs, to be a completely
correct and accurate binary-to-decimal floating-point conversion
algorithm. (It has been continuously punted in favor of the Common
LISP Manual.) It is my hope that this algorithm will prove suitable
for use in Common LISP implementations.
--Guy
∂17-Jun-83 1623 @MIT-MC:Cassels%SCRC-TENEX%MIT-MC@SU-DSN Rounding on output
Received: from MIT-MC by SU-AI with TCP/SMTP; 17 Jun 83 16:23:18 PDT
Received: from SCRC-MENOTOMY by SCRC-TENEX with CHAOS; Fri 17-Jun-83 19:09:04-EDT
Date: Friday, 17 June 1983, 19:25-EDT
From: Robert A. Cassels <Cassels%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Rounding on output
To: Fahlman%CMU-CS-C@SU-DSN, Cassels%SCRC-TENEX%MIT-MC@SU-DSN
Cc: Common-Lisp@SU-AI
In-reply-to: The message of 16 Jun 83 20:59-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: Thu, 16 Jun 1983 20:59 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
Do we really have to lay down complicated rules for rounding of printed
flonums in the white pages? I can't believe that all of these marginal
cases matter. Why don't we just say that the results are supposed to be
rounded appropriately and let the implementors worry about overflow
conditions and how to break ties and what is done with the last bit.
What happens on ties hardly matters, since there is only one value of
exponent for which ties can occur.
In general, I agree that accuracy in printing isn't so important.
But there are enough strange behaviors when you drop a few bits
that I believe it's worth the trouble. If Common Lisp is to be
used for any sort of serious mathematical work, any rigor we can
introduce will be appreciated down the road. Why stop with
rational numbers?
I would certainly like the reader to be accurate. Otherwise it's
a real pain to write approximation routines with nice properties
-- like monotonicity. Are we to be reduced to writing octal
constants just to be sure that all the bits are right?
How do you write PI (which is supposed to be "the best possible
approximation") in a machine-independent manner?
∂18-Jun-83 2053 FAHLMAN@CMU-CS-C MEMBER
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 18 Jun 83 20:53:03 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 18 Jun 83 23:51:58 EDT
Date: Sat, 18 Jun 1983 23:51 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: common-lisp@su-ai
Cc: RMS@mit-mc
Subject: MEMBER
Richard Stallman phoned me today with an urgent request that we
reconsider our earlier decision to have a MEMBER function that uses EQL
as the default test. He wants us to use MEMBERP (or some other name)
for this, so that various compatibility packages can go on providing
MEMBER as a function with an EQUAL test.
At one point, several of us (including me) advocated this move, but
nobody could come up with a good name for the EQL-defualt version of
MEMBER. I think that MEMBERP was considered at one point, but was
rejected as being inconsistent with the way we are naming the other
sequence and list functions. (No "P"'s hanging from any of the others.)
Finally, either on the August '82 ballot or at the meeting, we decided
to go with MEMBER as the name of the EQL-defualt function. It was
observed that any file consistently using MEMBER in the old way could be
translated automatically to (MEMBER x y :TEST #'EQUAL). Since then, a
lot of code has been written that uses the new form of MEMBER, so there
is a cost of converting new code back to balance against the cost of
converting old code forward.
I pointed out that we had frozen the manual, but RMS felt that this
should be made a special case on the following grounds:
1. It is a trivial change that could be put into the manual and into our
implementations at the last minute.
2. This issue is so important to him and to his user community that he
would probably split with Common Lisp rather than convert to the
new-style MEMBER.
3. Stallman (and, he says, also Greenblatt) was somehow under the
impression that we had decided in August to leave MEMBER alone.
He only just realized that the manual contradicts this, and was also
taken by surprise by the "flag day" freeze -- he has not been following
the Common Lisp mailing list.
I am opposed to reopening this issue or any other issue at this point.
However, I did agree to send a query to the Common Lisp mailing list to
see whether there is significant support for this change, given
Stallman's position. I am not in a position to assess how critical
Stallman's implementation effort is to Lisp Machine users at MIT or
what the effect might be of a split over this issue, so I didn't want to
unilaterally rule out any change in our position. Opinions?
-- Scott
∂18-Jun-83 2158 RPG Funargs
To: fahlman@CMU-CS-C, "#COMMON.MSG[COM,LSP]"@SU-AI
When I talked to RMS a month ago he convinced me that maybe my thinking on
funargs was not deep enough. Since then I've been hacking closures in the
S-1 Lisp compiler, and I think that I like the rules the way they are. For
us the key technical problem is a register-allocation one because we refer
to closure variables by offset to a nailed-down register within the
closure, and by offset to an allocated register from outside the closure
where that variable is lexically apparent. So, each procedure has a
closure-pointer (CP) register that points to pointer and non-pointer
temporaries for that closure. A free variable within a closure resides in
this area as a pointer temporary. So in the function:
(defun foo (x)
((lambda ((&function f))
(setq x 7)
(* (f x)(f (* x 2))))
(lambda (y)(* x y))))
the variable x resides within the procedure (closure) which is defined by
(lambda (y)(* x y))))
This variable is referenced by offset to the CP which corresponds to this
procedure. In FOO, it is referred to by offset to a register (or pseudo-register)
that contains the CP for the closure). Therefore, the (setq x 7) effects the
closure after it is logically created.
Since pseudo-registers (the ability to use a memory location as a register
in all register-like addressing modes) are as fast as registers, this
implementation has no post-compile-time penalty that I can see.
Our compiler can (or will) do all the analysis we need for this. In
addition, our assembler can assemble n functions in parrallel and
deduces appropriate addressing modes for exactly this problem.
S-1 has hairy enough addresing modes that at the moment I am willing to
state that the S-1 has no trouble with the rules the way they are.
Maybe next week after I've hacked more I won't like them.
RMS mentioned that on Lisp machines he can use invisible pointers to
do the indirection easily. I claim that he is using the power of his
hardware to overcome a weakness in his compiler. The S-1 hardware helps
us a little too, but at worst we would have to allocate a pointer register
to hold this offset register for the closure.
Since you have not heard from me on this you could have concluded that
either it wasn't a problem for the S-1 or else that I thought that
the language benefit was worth the trouble.
This rambles, but I'm trying to convince myself that I'm justified in
being happy with things. I don't believe much in implementation woes
as language-design criteria.
-rpg-
∂19-Jun-83 1108 @MIT-MC:RMS%MIT-OZ%MIT-MC@SU-DSN MEMBER, etc.
Received: from MIT-MC by SU-AI with TCP/SMTP; 19 Jun 83 11:08:44 PDT
Date: Sunday, June 19, 1983 2:05PM-EDT
From: Richard M. Stallman <RMS%MIT-OZ%MIT-MC@SU-DSN>
Subject: MEMBER, etc.
To: common-lisp at SU-AI
It seems that people are starting to discuss the question
of whether they, and the users of their Lisp systems,
will benefit from renaming MEMBER to MEMBERP in Common Lisp.
This subject is relevant to the question of whether to rename
it, but is not the same subject. If anyone finds that his users
would benefit from the renaming, that is an additional reason
to make the renaming. But the fact that some Lisp system,
such as NIL, has changed MEMBER, or is willing to change MEMBER,
only means the absense of a reason to rename the function in
Common Lisp. It is not any sort of reason NOT to rename it.
If the renaming were done, presumably GSB would not want to
change the definition of MEMBER a second time. That is fine.
Common Lisp would no longer define MEMBER and there would be
no reason he had to change it. Nobody would have to change it.
NIL users would not be inconvenienced.
There are only two reasons I can see which could be used
to argue against the change:
1) the name MEMBER is a nicer name than MEMBERP (if it is one)
2) some people have written portable code that uses MEMBER.
It seems clear that the amount of such portable code is small
at this date compared to the amount of Lisp machine code.
1) is a matter of opinion and one could see it either way.
The functions that are the problem are MEMBER, ASSOC, RASSOC,
DELETE etc. and REMOVE etc. This is what I suggest to do about
them:
MEMBER -> MEMBERP
ASSOC, RASSOC:
Delete them. It is easy to use FIND for this purpose,
as described in the documentation of FIND.
This can be seen as making the design cleaner.
REMOVE:
Rename to FILTER, and change the sense of the test.
That is, change :TEST to :TEST-NOT and vice versa;
an element is kept if it passes the test.
DELETE
Rename to NFILTER and change the sense of the test.
SUBSET is a possible alternative to FILTER.
Or perhaps REMOVE -> FIlTER-MATCH,
REMOVE-IF-NOT -> FILTER, REMOVE-IF -> FILTER-NOT.
∂19-Jun-83 1340 @MIT-MC:RMS%MIT-OZ%MIT-MC@SU-DSN
Received: from MIT-MC by SU-AI with TCP/SMTP; 19 Jun 83 13:40:17 PDT
Date: 19 Jun 1983 1613-EDT
From: RMS%MIT-OZ%MIT-MC@SU-DSN
To: common-lisp@SU-AI
I have asked the Lisp machine user community to say how
important they consider the issue of MEMBER, etc.
I will accumulate the replies and inform people of
how the user community feels in a couple of days.
It seems that there is a responsibility to ask them,
not just system implementors and designers,
since the decision will impact them as much as us.
-------
∂19-Jun-83 1342 HEDRICK@RUTGERS.ARPA Re: MEMBER
Received: from RUTGERS by SU-AI with TCP/SMTP; 19 Jun 83 13:42:29 PDT
Date: 19 Jun 83 16:41:37 EDT
From: Dir LCSR Comp Facility <HEDRICK@RUTGERS.ARPA>
Subject: Re: MEMBER
To: Fahlman@CMU-CS-C.ARPA
cc: common-lisp@SU-AI.ARPA, RMS@MIT-MC.ARPA
In-Reply-To: Message from "Scott E. Fahlman <Fahlman@CMU-CS-C>" of 18 Jun 83 23:51:00 EDT
In general I favor any move that would cause Common Lisp to be more
compatible with Lisp. I would be completely unsympathetic to someone
who said that he needed a last-minute new feature. But in my opinion it
is never too late to move back towards Lisp.
-------
∂19-Jun-83 1411 FAHLMAN@CMU-CS-C
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 19 Jun 83 14:11:33 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 19 Jun 83 17:10:42 EDT
Date: Sun, 19 Jun 1983 17:10 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: RMS%MIT-OZ%MIT-MC@SU-DSN
Cc: common-lisp@SU-AI
In-reply-to: Msg of 19 Jun 1983 16:13-EDT from RMS%MIT-OZ%MIT-MC at SU-DSN
Please send a copy of your query on MEMBER to Common-Lisp@su-ai so that
we can see exactly what people are responding to. Thanks.
-- Scott
∂19-Jun-83 1452 @MIT-MC:RMS@MIT-OZ Function MEMBER to be changed?
Received: from MIT-MC by SU-AI with TCP/SMTP; 19 Jun 83 14:52:42 PDT
Return-path: <RMS@MIT-OZ>
Mail-From: RMS created at 19-Jun-83 08:16:55
Date: Sunday, June 19, 1983 8:16AM-EDT
From: Richard M. Stallman <RMS@MIT-OZ>
Subject: Function MEMBER to be changed?
To: info-lispm-mit at MIT-OZ
Remailed-date: 19 Jun 1983 1752-EDT
Remailed-from: RMS%MIT-OZ%MIT-MC@SU-DSN
Remailed-to: common-lisp@SU-AI
It happens that the Common Lisp plan involves changing the function MEMBER
(and ASSOC and DELETE and REMOVE) to use EQL instead of EQUAL for comparison.
(EQL is like = on numbers, like EQ on everything else).
I have urged them to call the new functions MEMBERP and other new names
so that the old names MEMBER, ASSOC, etc. can be unchanged.
I expect most of you prefer to have the existing names not change their
meanings. I'd like to know whether you think this is important.
Please send me mail about what you feel about this, and I will
pass it on to the Common Lisp designers. (If you prefer to have
MEMBER change, you can tell me that.)
∂19-Jun-83 1558 KMP@MIT-MC MEMBER, MEMBERP
Received: from MIT-MC by SU-AI with TCP/SMTP; 19 Jun 83 15:58:03 PDT
Date: 19 June 1983 18:57 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
Subject: MEMBER, MEMBERP
To: Common-Lisp @ SU-AI
cc: RMS @ MIT-MC
When this subject came up the last time, it was argued by several people that
most usages of MEMBER were due to people using numbers in lists, since numbers
aren't guaranteed EQ. It was argued that most people were using MEMBER where
they really didn't need all its power. I was mildly against this move when it
originally came up, but in checking back over pieces of code I've written,
there are very few places where it would matter and I'm inclined to buy the
argument that those few places should be changed in the mechanical way
suggested in order to clean up the language.
I think the right approach to any compatibility packages might be to make
a MACLISP: package which people could build inferiors to if they didn't like
LISP:. It could shadow things like MEMBER, etc. and define them with the old
semantics.
I can't believe this problem is the only one of its kind in Common Lisp. There
are other incompatible changes. Code will have to be looked over before it can
be said to be running correctly anyway. At this point, I see the goal of
compatibility to mean not that code would run directly but more that code
could be mechanically translated (rather than requiring major re-thinking)
in order to run. The implementors need to decide if this is in fact what they
intend. If the claim that CL really needs to run code compatibly with
existing dialects is true, there are a pile more changes we'd better start
making right now. If, instead, the claim is that the language will successfully
support a compatibility mode (eg, a MACLISP: package to build systems under,
or a MACLISP => COMMON-LISP translator), then I think the change to MEMBER is
certainly among the least dangerous of the changes being made and I think it's
a very poor precedent to set.
Common Lisp is, and always has been, dangerously on the brink of being too
wishy-washy to be a good language in and of itself. It has had to yield to the
needs of so many design constraints from so many applications that it's been
difficult to pull together. My feeling is that its overall effect will probably
be positive because it did actually rise above quibbles with absolute
compatibility and try to present itself as less of a hodge-podge than most of
the languages it seeks to make compatible. Regularization of naming and
semantics of operators where it has happened, even where the possibility
exists of introducing an incompatibility with some dialect, is perhaps the
most important contribution of the language.
I think we should just stand with the spec we've got, provide users with as
much data we can about mechanical rewrites they'll need to do -- perhaps even
programs to help with the rewrites -- and go with that.
∂19-Jun-83 1803 FAHLMAN@CMU-CS-C MEMBER, etc.
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 19 Jun 83 18:03:22 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 19 Jun 83 21:02:05 EDT
Date: Sun, 19 Jun 1983 21:02 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: common-lisp@su-ai
Cc: rms%mit-oz%mit-mc@su-dsn
Subject: MEMBER, etc.
I agree with Stallman that at this point we should not be discussing the
merits and aesthetics of MEMBER vs. MEMBERP. We did that once, and made
a decision. The time for aesthetic improvements to the language (first
edition) is over. For that reason, I find his poll of MIT users on
whether they want good old-fashioned MEMBER to stay the way it is to be
totally irrelevant to this discussion; last August, that might have been
valuable input, but not now.
I disagree strongly with Stallman's view that we have some obligation to
make his proposed changes unless someone comes up with a compelling
reason not to. Whether RMS heard about it or not, the manual is frozen
and the presumption must be strongly in favor of not making any changes
to it. It now requires a truly compelling reason to make any change.
We are considering the MEMBER => MEMBERP change, if at all, because it
is a sort of emergency request. Stallman's claim is that (1) changing
to MEMBERP is so trivial a change that we should consider it even at
this late date, (2) it costs existing implementations nothing to make
the change, and (3) it causes the MIT/LMI/Stallman implementation
terrible problems to leave MEMBER the way it currently is, with EQL as
the default. In other words, according to RMS, the cost to him of not
making the change is very much greater than cost to the rest of us of
making the change. That is the ONLY reason that I can see why a change
of this sort would be considered now.
After thinking about this issue, I now believe that all three of the
above-mentioned points are greatly exaggerated.
(1) As we see from RMS's note, the proposal now is to alter MEMBER,
ASSOC, RASSOC, DELETE, DELETE-IF, DELTE-IF-NOT, REMOVE, REMOVE-IF, and
REMOVE-IF-NOT. In several cases, the proposal involves changing the
sense of a test. The ASSOC and RASSOC functions are to be replaced with
uses of FIND. This is not such a trivial change any more.
(2) The claim is that since Common Lisp would no longer define MEMBER,
ASSOC, RASSOC, DELETE, DELETE-IF, DELETE-IF-NOT, REMOVE, REMOVE-IF, and
REMOVE-IF-NOT, those of us who have made the transition already (and our
users) could just leave these functions as they are and add the new
forms beside them. Thus, RMS claims, the cost of this conversion is zero
for us. I can't speak for the other implementations, but we at CMU are
quite strongly committed to working within the bounds of portable Common
Lisp wherever possible. This means that if MEMBER is not a part of
Common Lisp and MEMBERP is, we have to change our code to use MEMBERP.
RMS is technically correct -- if we didn't do this, our code would still
run -- but we are quite unwilling to have fossilized relics of earlier
editions of Common Lisp sprinkled through our system. So, in realistic
terms, the cost to us of making all of RMS's changes is far from zero.
I'm not saying that it is a terrible cost, but it is significant. A far
greater cost, in my opinion, would be the confusion in the minds of
those users who have already made the transition to the new Common Lisp
-- one of the most confusing things you can do is to make a decision on
something like this, sell people on it, and then reverse it six months
later.
(3) After giving the matter some thought, I no longer believe that a
one-time change-over to use the EQL versions of MEMBER and friends would
be such a big deal for RMS and his users. In the time he has spent
arguing about this, he could easily have implemented an Emacs or Zwei
command to turn all occurrences of (MEMBER x y) in a file into (MEMBER x
y :TEST #'EQUAL), and likewise for the other forms he's worried about.
He might not WANT to make the changeover, but it would not be the
terrible ordeal that he suggests. In fact, I believe that it would be
no more work for him to make that change than for us to make the changes
he proposes. A lot of people with a lot of working code have already
made that change, and have lived to tell about it.
So, while I thought it appropriate to bring Stallman's urgent request to
the attention of this list, my own opinion is that the case is not
strong enough to warrant making these changes to the language definition
at the last minute.
-- Scott
∂20-Jun-83 0914 RPG Funargs
∂18-Jun-83 2010 FAHLMAN@CMU-CS-C Funargs
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 18 Jun 83 20:10:29 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 18 Jun 83 23:09:14 EDT
Date: Sat, 18 Jun 1983 23:09 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: griss@utah-20, rpg@su-ai, gsb@mit-mc
Cc: steele@CMU-CS-C, fahlman@CMU-CS-C
Subject: Funargs
Richard Stallman called me tonight with a bunch of last minute issues
that he feels we really have to deal with. (He has not been reading the
Common Lisp mailing list -- too busy -- and did not know until too late
that we had frozen the manual definition earlier this week.)
He claimed that the current lexical binding scheme, in which funargs
work both upwards and downwards, is a major screw for stock hardware. I
pointed out that we had discussed this, and had also discussed the
possibility that some implementations might want to add a DOWNWARDS-ONLY
declaration to make these cases more efficient, and that we had decided
not to bother with this in the white pages, for now at least, because so
few variables have to be closed over in any event.
RMS felt that the default should be downwards-funarg-only, and that
users should have to ask specially if they want a lambda closed for
upward funarg use. He said that this didn't matter to him personally --
his implementation already does what the Common Lisp manual says -- but
he says that he has talked to a lot of people working on stock-hardware
implementations (you three in particular) and that most of these people
(you three in particular) were quite unhappy with the current scheme.
It seemed odd to me that none of you had said anything like this to
Common Lisp list or to me personally, but RMS challenged me to ask you
directly rather than assume that silence means acquiescence.
So, how about it? Do you all secretly believe that we punt the current
lexical binding rules and that we make downward-funarg-only the default,
with a declaration to get the other kind? Here's your chance to say so.
Speaking for the DEC Vax implementation (no hardware is more stock than
a Vax), I like the current rules just fine.
-- Scott
∂20-Jun-83 0915 RPG MEMBER
∂18-Jun-83 2053 FAHLMAN@CMU-CS-C MEMBER
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 18 Jun 83 20:53:03 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 18 Jun 83 23:51:58 EDT
Date: Sat, 18 Jun 1983 23:51 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: common-lisp@su-ai
Cc: RMS@mit-mc
Subject: MEMBER
Richard Stallman phoned me today with an urgent request that we
reconsider our earlier decision to have a MEMBER function that uses EQL
as the default test. He wants us to use MEMBERP (or some other name)
for this, so that various compatibility packages can go on providing
MEMBER as a function with an EQUAL test.
At one point, several of us (including me) advocated this move, but
nobody could come up with a good name for the EQL-defualt version of
MEMBER. I think that MEMBERP was considered at one point, but was
rejected as being inconsistent with the way we are naming the other
sequence and list functions. (No "P"'s hanging from any of the others.)
Finally, either on the August '82 ballot or at the meeting, we decided
to go with MEMBER as the name of the EQL-defualt function. It was
observed that any file consistently using MEMBER in the old way could be
translated automatically to (MEMBER x y :TEST #'EQUAL). Since then, a
lot of code has been written that uses the new form of MEMBER, so there
is a cost of converting new code back to balance against the cost of
converting old code forward.
I pointed out that we had frozen the manual, but RMS felt that this
should be made a special case on the following grounds:
1. It is a trivial change that could be put into the manual and into our
implementations at the last minute.
2. This issue is so important to him and to his user community that he
would probably split with Common Lisp rather than convert to the
new-style MEMBER.
3. Stallman (and, he says, also Greenblatt) was somehow under the
impression that we had decided in August to leave MEMBER alone.
He only just realized that the manual contradicts this, and was also
taken by surprise by the "flag day" freeze -- he has not been following
the Common Lisp mailing list.
I am opposed to reopening this issue or any other issue at this point.
However, I did agree to send a query to the Common Lisp mailing list to
see whether there is significant support for this change, given
Stallman's position. I am not in a position to assess how critical
Stallman's implementation effort is to Lisp Machine users at MIT or
what the effect might be of a split over this issue, so I didn't want to
unilaterally rule out any change in our position. Opinions?
-- Scott
∂20-Jun-83 0915 RPG Funargs
∂18-Jun-83 2348 FAHLMAN@CMU-CS-C Funargs
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 18 Jun 83 23:48:02 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 19 Jun 83 02:47:08 EDT
Date: Sun, 19 Jun 1983 02:47 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Dick Gabriel <RPG@SU-AI>
Subject: Funargs
In-reply-to: Msg of 18 Jun 83 2158 PDT from Dick Gabriel <RPG at SU-AI>
Dick,
Thanks for clarifying your position on this. I'm not sure I completely
follow your description of how the register hackery works -- too bad
netmail can't handle diagrams -- but I get the gist of it. We will be
doing something less clever on the Vax and paying a small price whenever
we need a closure, but since closed-over variables occur so
infrequently, this slight inefficiency doesn't bother me. By the time
users learn to really groove on this lexical stuff and use it a lot,
we'll probably have your portable super-compiler running for Vax, or
maybe someone else's.
Anyway, I'm glad to hear that you're not grossly unhappy over the
current rules. I'd hate to have to explain to a naive user what a
downward-only funarg is and why these are the default.
-- Scott
∂20-Jun-83 0915 RPG Funargs
∂19-Jun-83 0025 GSB@MIT-ML Funargs
Received: from MIT-ML by SU-AI with TCP/SMTP; 19 Jun 83 00:25:38 PDT
Date: 19 June 1983 03:25 EDT
From: Glenn S. Burke <GSB @ MIT-ML>
Subject: Funargs
To: Fahlman @ CMU-CS-C
cc: GSB @ MIT-ML, rpg @ SU-AI, griss @ UTAH-20, steele @ CMU-CS-C
Stallman and i talked about this at some length not too long ago, including
some implementation possibilities. I then talked about it with Moon,
and what resulted was the brief discussion we had.
I was easily convinced that full funarging as a default is not
unreasonable. Given that, my willingness to let the issue hang for
now is based on various pragmatic issues. (I AM assuming that we will
take it up again.) Basically, the NIL variable binding mechanism uses
shallow binding for both special and (in the interpreter) lexical
variables. The compiler does not handle any kind of lexical closures
whatsoever right now. The mechanism is designed for ease of doing
full funarging. I see three different cases for me to handle with
lexical closures: the completely general upwards case, the case
(which has to be declared) downwards only, but where not all usages of
the function are lexically apparent to the compiler (i.e., someone
goes (random-function #'foo)), and cases where all uses of the
function are lexically apparent (and so the compiler can pass hidden
arguments or something like that). Because i do not anticipate
dealing with this stuff very soon, i expect that the first pass which
would handle compiled closures would use the same approach the
interpreter takes, the difference being that the compiler can resolve
all usages, and that what happens for closure entry and variable
reference would be about the same as that for binding and referencing
special variables. The second stage would be to deal with the case
where all the closure usages were lexically apparent; this seems
simple enough that i expect it would be put in initially anyway. This
is why I am not pressing for any sort of immediate solution or
decision on this.
It is hard to analyze or anticipate how prevalent the second of those
three situations will be. Because I am always aware of what my
implementation is capable of, I never push it too hard. However, full
funargs have always worked in the NIL interpreter (and now it even
encloses lexical instance variables of flavor instances correctly).
The result of this is that I have been receiving comments of the
nature "boy, it will be nice when you have lexical closures working".
Almost invariably these are downwards-only funargs, in fact those
which could be trivially rewritten by changing a small number of
variables to be special, Maclisp-style, as in
(defun frob ()
(let ((*foo* nil)) (mapatoms #'(lambda (x) reference *foo*)) ...))
It is the fact that we purport to support such a coding style which
leads people to use it. I believe that this is at least part of the
reason that Richard thinks that downwards-only should be the default
case. My own opinion is that, as with arithmetic, the more general
usage should be the default, and we should have a declaration for
those who desire to gain efficiency in cases like this.
Because of this and our previous discussions, I am fully expecting
that we will have a downwards-only declaration in the works by the
time i get around to actually implementing it; if not, i will add it
as an NIL-only extension.
∂20-Jun-83 0915 RPG Function MEMBER to be changed?
∂19-Jun-83 0522 @MIT-MC:RMS%MIT-OZ%MIT-MC@SU-DSN Function MEMBER to be changed?
Received: from MIT-MC by SU-AI with TCP/SMTP; 19 Jun 83 05:22:40 PDT
Date: Sunday, June 19, 1983 8:16AM-EDT
From: Richard M. Stallman <RMS%MIT-OZ%MIT-MC@SU-DSN>
Subject: Function MEMBER to be changed?
To: info-lispm-mit at MIT-OZ
It happens that the Common Lisp plan involves changing the function MEMBER
(and ASSOC and DELETE and REMOVE) to use EQL instead of EQUAL for comparison.
(EQL is like = on numbers, like EQ on everything else).
I have urged them to call the new functions MEMBERP and other new names
so that the old names MEMBER, ASSOC, etc. can be unchanged.
I expect most of you prefer to have the existing names not change their
meanings. I'd like to know whether you think this is important.
Please send me mail about what you feel about this, and I will
pass it on to the Common Lisp designers. (If you prefer to have
MEMBER change, you can tell me that.)
∂20-Jun-83 0916 RPG RMS's phone call
∂19-Jun-83 0556 @MIT-MC:DLW@SCRC-TENEX RMS's phone call
Received: from MIT-MC by SU-AI with TCP/SMTP; 19 Jun 83 05:56:11 PDT
Date: Sunday, 19 June 1983 08:53-EDT
From: DLW at SCRC-TENEX
To: Fahlman at cmu-cs-c
cc: common-lisp-implementors at SCRC-TENEX, Steele at cmu-cs-c,
rpg at sail
Subject:RMS's phone call
This is difficult to answer, because it raises not only a technical issue,
but a host of political issues as well. At the outset I should remark that
it's a bit difficult for me to be confident that I can deal fairly with
RMS. He currently refuses to acknowledge my existence if we pass on the
street. He has widely advertised that Symbolics, an effort that I and my
colleagues have dedicated ourselves to for the last few years, is a work of
great evil, and likewise re those of us who work for it; indeed, he has put
such great time and effort into slandering us that it's hard for me to
convey it.
On one hand, I am tempted to ask, "Who is he to suggest that we make
incompatible changes, and after the official freeze date too? Why didn't
he know about MEMBER? The rest of us put in lots of effort reading and
re-reading draft manuals, and participating in the mail; where was he?" On
the other hand, I don't feel completely justified in saying that, since
we did indeed exclude him from the big meetings (although not from the
mail), and so to some extent discouraged him from participating.
I am also tempted to ask, "If he's been so out-of-touch with what's going
on, how do we know he won't discover some other language point that he
doesn't like, a month or two from now, and again threaten to withdraw?" Of
course, we can always tell him now that we're only accepting this change
because it's so close after flag day and next time we really won't.
You asked about whether his user community is significant, etc. As you
probably know, RMS and Symbolics forked sources over a year ago, and two
systems are maintained; one at Symbolics, and one at MIT and LMI. All
customers use the system provided by their respective companies; MIT users
are split, some using one and some using the other, and some even switch
back and forth. Now, I cannot give you an accurate report on LMI's customer
base. We did learn recently that LMI hasn't sold any more CADRs since we
started delivering 3600's (the beginning of this year), and it is extremely
likely that they'll never sell any CADRs again. Last year at the AAAI, as
you probably recall, LMI said that they would be showing the "Lambda", their
new machine, and it didn't show up. The current state of the "Lambda" (we
just got an update recently from a former LMI employee) is that they have
one initial prototype that doesn't work at all and has been discarded; one
that executes microinstructions, but at half the design speed; and one that
is supposed to fix the speed problems, but is still being debugged. We are
pretty sure that they have yet to bring up a working Lisp system at all.
As a reference, it was one year between the time we got Lisp starting to
work, and the time we shipped the first machines to customers. Symbolics
expects to deliver 30 machines per month to customers (this does NOT
constitute an official statement of Symbolics nor is it any kind of a promise,
but that's our internal projection and it looks realistic since they did
25 last month), and then we'll start ramping up.
So, personally, I think we'll have hundreds of machines in the field before
LMI ships a single Lambda, and I don't think they have much chance of
success. However, you obviously realize that you're hearing this from a
competitor who doesn't like them very much, so you'll have to decide how
to discount what I say and come to your own conclusions somehow.
You specifically asked how RMS's withdrawl from the effort would affect
users at MIT. One part of the answer is that they can always use the
Symbolics version of the system. The only thing stopping them is that
anybody at MIT who uses the Symbolics version gets personally harassed,
nagged, and berated by Stallman. Quite a few people use it anyway.
By the way, the motivation for his request reflects his overall
implementation strategy. Whereas we are introducing a compatibility
package, so that we'll support Zetalisp (our old dialect, henceforth ZL)
and Common Lisp (CL) in parallel and let our users convert over at their
own pace, RMS instead plans to convert his ZL into CL by a series of new
releases, some containing incompatible changes. Thus, his motivation to
increase Maclisp compatibility is much greater than ours (or anyone
else's). My real worry about RMS's threat is my doubt that he will really
conform to the spec even if we comply with the request. If you know RMS,
you probably know that his philosophy is to do what he thinks is Right,
even if (especially if) it conflicts with what the Authority thinks is
right. The very idea of RMS being willing to conform to a language spec
that he doesn't completely and fully agree with is hard to entertain. I
rather suspect that he'd eventually end up supporting "RMS's improved
Common Lisp, with all the brain-damage fixed". Again, you have to make
your own judgements about his character.
What I really don't know is whether he appreciates the problems with such a
strategy. MEMBER is hardly the only function being changed incompatibly.
How much does he think he can help them by reducing by one the large number
of incompatible changes that need to be made to convert from Maclisp/ZL
to CL?
About the proposal itself (ah, finally), the first question I have is what
happens to DELETE, ASSOC, et al? Does DELETE use EQUAL, and we introduce
DELETEP to use EQL? Or does DELETE use EQL while MEMBER uses EQUAL, and
ther's no EQUAL-version of DELETE, and we live with the asymmetry? Neither
seems at all acceptable. The proposal as it stands being the latter of
these, I must strongly object to it.
Even if he comes up with a debugged proposal, I still support our decision
to use the "good" names for the "approved" equality predicate. We decided
quite some time ago that syntactic compatibility with Maclisp was not so
important as major language cleanups, particularly when a mechanical
conversion from Maclisp can be done in a straightforward way; in fact,
this was the decision that lead us to our present "compatibility package"
implementation strategy. However, I'm willing to look over a debugged
proposal.
∂20-Jun-83 0916 RPG Funargs
∂19-Jun-83 0821 FAHLMAN@CMU-CS-C Funargs
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 19 Jun 83 08:21:05 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 19 Jun 83 11:19:49 EDT
Date: Sun, 19 Jun 1983 11:19 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Glenn S. Burke <GSB@MIT-ML>
Cc: griss@UTAH-20, rpg@SU-AI, steele@CMU-CS-C
Subject: Funargs
In-reply-to: Msg of 19 Jun 1983 03:25 EDT from Glenn S. Burke <GSB at MIT-ML>
Glenn,
Thanks for the clarification. Your position is what I thought it was.
I am sure that whenever someone is ready to make use of a
DOWNWARD-FUNARG-ONLY declaration, there will be no problem with adding
this as a standard (modulo some discussion to find a good name and
syntax).
-- Scott
∂20-Jun-83 0916 RPG RMS's phone call
∂19-Jun-83 0913 FAHLMAN@CMU-CS-C RMS's phone call
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 19 Jun 83 09:12:57 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 19 Jun 83 12:11:47 EDT
Date: Sun, 19 Jun 1983 12:11 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: DLW%SCRC-TENEX@mit-mc
Cc: rpg@SU-AI, Steele@CMU-CS-C
Subject: RMS's phone call
In-reply-to: Msg of 19 Jun 1983 08:53-EDT from DLW at SCRC-TENEX
I share all of your concerns about the political implications of
re-opening the language definition under these conditions.
Specifically about the MIT situation: You mention that people there have
a choice about whether to use the Symbolics or MIT/Stallman software.
It would help me to have a clearer picture of how real the Symbolics
option is. The real question I have is whether, if Stallman goes off
and does something non-standard, he forces a lot of people to go along
with him. If they follow voluntarily, that's their problem.
Can you give me some idea of how many people are using which software on
the MIT machines? Does Symbolics tangle the MIT users up with gross
amounts of red tape when they need access to sources and such? Does it
cost MIT people extra to use the Symbolics software? And (the big
question) is the Symbolics Common Lisp implementation going to run on
the old MIT machines, or just on the 3600's?
-- Scott
∂20-Jun-83 0916 RPG Function MEMBER to be changed?
∂19-Jun-83 0917 @MIT-MC:ZVONA%MIT-OZ%MIT-MC@SU-DSN Function MEMBER to be changed?
Received: from MIT-MC by SU-AI with TCP/SMTP; 19 Jun 83 09:17:42 PDT
Date: Sun, 19 Jun 1983 11:55 EDT
From: ZVONA%MIT-OZ%MIT-MC@SU-DSN
To: Richard M. Stallman <RMS%MIT-OZ%MIT-MC@SU-DSN>
cc: info-lispm-mit%MIT-OZ%MIT-MC@SU-DSN
Subject: Function MEMBER to be changed?
In-reply-to: Msg of 19 Jun 1983 08:16-EDT from Richard M. Stallman <RMS>
Surely Common Lisp conversion will entail many other changes in code.
Why is this particular change important?
∂20-Jun-83 0917 RPG Upward/downward funarg
∂19-Jun-83 0929 FAHLMAN@CMU-CS-C Upward/downward funarg
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 19 Jun 83 09:28:55 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 19 Jun 83 12:27:31 EDT
Date: Sun, 19 Jun 1983 12:27 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: rms%mit-oz@MIT-MC
Cc: rpg@su-ai, gsb@mit-mc, griss@utah-20, steele@CMU-CS-C
Subject: Upward/downward funarg
I have now heard from both Gabriel and Burke on the issue of funarg
direction. Both said that they had had some reservations about
efficient implementation of the current binding rules when they last
spoke to you, but that they have largely resolved these problems and now
favor leaving the rules as they are. GSB did express his desire for a
DOWNWARD-FUNARG-ONLY declaration to be added to the standard language at
some time in the future, and this will happen whenever someone gets to
the point where he is ready to make use of such a declaration. For the
Vax implementation that we are doing with DEC, we do not have a way to
make both-direction funargs quite as efficient as downward-only would
be, but we consider the difference (and the extra consing) to be totally
insignificant.
So, unless Griss weighs in with violent opposition to the current
scheme, which would surprise me a lot, I think that the people working
on stock hardware have agreed to the current rules, and the matter is
closed.
-- Scott
∂20-Jun-83 0917 RPG MEMBER, etc.
∂19-Jun-83 1108 @MIT-MC:RMS%MIT-OZ%MIT-MC@SU-DSN MEMBER, etc.
Received: from MIT-MC by SU-AI with TCP/SMTP; 19 Jun 83 11:08:44 PDT
Date: Sunday, June 19, 1983 2:05PM-EDT
From: Richard M. Stallman <RMS%MIT-OZ%MIT-MC@SU-DSN>
Subject: MEMBER, etc.
To: common-lisp at SU-AI
It seems that people are starting to discuss the question
of whether they, and the users of their Lisp systems,
will benefit from renaming MEMBER to MEMBERP in Common Lisp.
This subject is relevant to the question of whether to rename
it, but is not the same subject. If anyone finds that his users
would benefit from the renaming, that is an additional reason
to make the renaming. But the fact that some Lisp system,
such as NIL, has changed MEMBER, or is willing to change MEMBER,
only means the absense of a reason to rename the function in
Common Lisp. It is not any sort of reason NOT to rename it.
If the renaming were done, presumably GSB would not want to
change the definition of MEMBER a second time. That is fine.
Common Lisp would no longer define MEMBER and there would be
no reason he had to change it. Nobody would have to change it.
NIL users would not be inconvenienced.
There are only two reasons I can see which could be used
to argue against the change:
1) the name MEMBER is a nicer name than MEMBERP (if it is one)
2) some people have written portable code that uses MEMBER.
It seems clear that the amount of such portable code is small
at this date compared to the amount of Lisp machine code.
1) is a matter of opinion and one could see it either way.
The functions that are the problem are MEMBER, ASSOC, RASSOC,
DELETE etc. and REMOVE etc. This is what I suggest to do about
them:
MEMBER -> MEMBERP
ASSOC, RASSOC:
Delete them. It is easy to use FIND for this purpose,
as described in the documentation of FIND.
This can be seen as making the design cleaner.
REMOVE:
Rename to FILTER, and change the sense of the test.
That is, change :TEST to :TEST-NOT and vice versa;
an element is kept if it passes the test.
DELETE
Rename to NFILTER and change the sense of the test.
SUBSET is a possible alternative to FILTER.
Or perhaps REMOVE -> FIlTER-MATCH,
REMOVE-IF-NOT -> FILTER, REMOVE-IF -> FILTER-NOT.
∂20-Jun-83 0917 RPG Change in MEMBER, etc.
∂19-Jun-83 1114 @MIT-MC:RMS%MIT-OZ%MIT-MC@SU-DSN Change in MEMBER, etc.
Received: from MIT-MC by SU-AI with TCP/SMTP; 19 Jun 83 11:13:59 PDT
Date: Sunday, June 19, 1983 2:06PM-EDT
From: Richard M. Stallman <RMS%MIT-OZ%MIT-MC@SU-DSN>
Subject: Change in MEMBER, etc.
To: info-lispm-mit at MIT-OZ
It should be noted that the possible change to MEMBER
and related functions would apply to users of Symbolics
systems as well.
∂20-Jun-83 0917 RPG RMS's phone call
∂19-Jun-83 1201 @MIT-MC:DLW%SCRC-TENEX%MIT-MC@SU-DSN RMS's phone call
Received: from MIT-MC by SU-AI with TCP/SMTP; 19 Jun 83 12:01:36 PDT
Received: from SCRC-BORZOI by SCRC-TENEX with CHAOS; Sun 19-Jun-83 14:59:58-EDT
Date: Sunday, 19 June 1983, 15:00-EDT
From: Daniel L. Weinreb <DLW%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: RMS's phone call
To: Fahlman%CMU-CS-C@SU-DSN
Cc: rpg@SU-AI, Steele%CMU-CS-C@SU-DSN, moon%SCRC-TENEX%MIT-MC@SU-DSN,
mmcm%SCRC-TENEX%MIT-MC@SU-DSN, dlw%SCRC-TENEX%MIT-MC@SU-DSN
In-reply-to: The message of 19 Jun 83 12:11-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Can you give me some idea of how many people are using which software on
the MIT machines?
I don't have a very good numerical idea of how many people at MIT are
using the LMI/MIT version versus how many are using the Symbolics
version. The Symbolics-manufactured machines (MIT now has 2 LM-2's and
about three 3600s) all run the Symbolics version. You can't run the MIT
version on the 3600. The AI lab has six more 3600s on order, and other
LCS people have a bunch more. Of the MIT-manufactured machines,
apparently some of the 7th-floor ones (the Sussman/Minsky/Knight group)
and the Programmer's Apprentice project run the Symbolics version, and
the rest of the AI lab seems to run the LMI/MIT version; this has been
the situation for about a year now.
Does Symbolics tangle the MIT users up with gross
amounts of red tape when they need access to sources and such?
No. Copies of the installed Symbolics software are placed (by us) onto
OZ (the AI lab's -20). And MIT people can access our system sources
over the microwave link, too (read-only).
Does it
cost MIT people extra to use the Symbolics software?
No. Whenever we release software to customers, MIT gets it too (actually
MIT usually gets it first), including sources.
And (the big
question) is the Symbolics Common Lisp implementation going to run on
the old MIT machines, or just on the 3600's?
We have done most of the development of the compatibility package on the
LM-2, which is the same as the old MIT machines. The package will
definitely run on both machines. However, full lexical scoping, which
we haven't started on implementing yet, may never work completely on the
LM-2.
The real question I have is whether, if Stallman goes off
and does something non-standard, he forces a lot of people to go along
with him. If they follow voluntarily, that's their problem.
To be fair, even though technically they can choose to run either
system, politically the local users are strongly "encouraged" to run the
LMI/MIT version because otherwise RMS will stop talking to them, and
stop fixing their bugs and helping them out. So to some extent if RMS
doesn't support Common Lisp, those people will be in a bind, and will be
discouraged from using Common Lisp as well. I don't know how to measure
the magnitude of this effect.
To get the side of the story other than the Symbolics side, you might
want to call up some AI lab staff person (you must know a lot of them
who are still around) and ask them what they think. Most of the
old-line vision and robotics hackers use the LMI/MIT version, and you
could ask them what they'd do if only the Symbolics version supported
Common Lisp. Of course, MIT AI people have never been very big on
standard languages, or operating systems, or computers, in the first
place; they always seem to be using home-grown...
∂20-Jun-83 0917 RPG RMS's phone call
∂19-Jun-83 1212 FAHLMAN@CMU-CS-C RMS's phone call
Received: from SU-DSN by SU-AI with PUP; 19-Jun-83 12:12 PDT
Received: From CMU-CS-C by SU-DSN.ARPA; Sun Jun 19 12:13:22 1983
Received: ID <FAHLMAN@CMU-CS-C>; 19 Jun 83 15:10:43 EDT
Date: Sun, 19 Jun 1983 15:10 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Daniel L. Weinreb <DLW%SCRC-TENEX@MIT-MC>
Cc: mmcm%SCRC-TENEX@MIT-MC, moon%SCRC-TENEX@MIT-MC,
rpg%SU-AI@SU-DSN, Steele@CMU-CS-C
Subject: RMS's phone call
In-reply-to: Msg of 19 Jun 1983 15:00-EDT from Daniel L. Weinreb <DLW%SCRC-TENEX at MIT-MC>
OK, thanks for the additional info. Sounds to me like RMS has the
ability to cause significant short-term pain to those folks, but not the
sort of critical hold over them that would give him a veto.
-- Scott
∂20-Jun-83 0918 RPG
∂19-Jun-83 1340 @MIT-MC:RMS%MIT-OZ%MIT-MC@SU-DSN
Received: from MIT-MC by SU-AI with TCP/SMTP; 19 Jun 83 13:40:17 PDT
Date: 19 Jun 1983 1613-EDT
From: RMS%MIT-OZ%MIT-MC@SU-DSN
To: common-lisp@SU-AI
I have asked the Lisp machine user community to say how
important they consider the issue of MEMBER, etc.
I will accumulate the replies and inform people of
how the user community feels in a couple of days.
It seems that there is a responsibility to ask them,
not just system implementors and designers,
since the decision will impact them as much as us.
-------
∂20-Jun-83 0919 RPG Changes to MEMBER, ASSOC, etc.
∂19-Jun-83 1729 @MIT-MC:KMP%MIT-OZ%MIT-MC@SU-DSN Changes to MEMBER, ASSOC, etc.
Received: from MIT-MC by SU-AI with TCP/SMTP; 19 Jun 83 17:29:35 PDT
Date: Sun, 19 Jun 1983 20:18 EDT
From: KMP%MIT-OZ%MIT-MC@SU-DSN
To: INFO-LISPM-MIT%MIT-OZ%MIT-MC@SU-DSN
Subject: Changes to MEMBER, ASSOC, etc.
RMS failed to note in his message the following relevant points.
* The proposed definitions for MEMBER, ASSOC, etc. are compatible with all
the cases of the current ASSOC except in the case of searching for list
or string in list structure. Since Maclisp has no strings, Maclisp
compatibility is affected only in the case where people do
(MEMBER '(B C) '((A B) (B C) (C D)))
which in Maclisp used to return ((B C) (C D)) and under the proposed
definition would return NIL. On the LispM, the additional case of doing
(MEMBER "BAR" '("FOO" "BAR" "BAZ"))
which used to return ("BAR" "BAZ") would return NIL. Under the proposed
standard, this would return NIL.
* In both of the cases written above, you can simply mechanically rewrite
your code. eg,
(MEMBER '(B C) '((A B) (B C) (C D)) :TEST #'EQUAL)
or (MEMBER "BAR" '("FOO" "BAR" "BAZ") :TEST #'EQUAL)
In the cases where you've written
(MEMBER C '(#/A #/B #/C))
or (MEMBER N '(1 2 3 4))
or (MEMBER X '(1.0 2.0 3.0))
you need change nothing, you'll just find that in some implementations your
code may run a little faster.
The only thing that's in question is what the default test is.
* The reason for changing the default test (which will be by a new function
EQL, which is like EQ except it can also compare characters or numbers)
is that it will allow searches for numbers and characters (which is believed
to be the most common use of MEMBER) to be more conveniently expressed.
eg, it used to be that
(MEMQ C '(#/A #/B #/C #/D))
was guaranteed to work only on the LispM because in Maclisp numbers were not
necessarily EQ and could not be searched for in some cases by MEMQ. (It
happens to work in some cases, but not all of them). The only alternative
previously was to write
(MEMBER C '(#/A #/B #/C #/D))
which compiles inefficiently because it invokes an EQUAL test rather than
a simpler test. Similar arguments can be made about searching for flonums.
In the rarer cases of searching for strings or s-expressions, the intent
of the current proposed definition is that you'd then use the clumsier
case of (MEMBER thing list :TEST test), specifying #'EQUAL, #'STRING-EQUAL,
or whatever.
The :TEST argument will remain; that functionality is not in question. The
real questions which RMS is getting at are the following two:
(A) If you had no code you were worried about keeping compatible and you were
just writing code from scratch, do you think EQL or EQUAL would be the more
reasonable default predicate for MEMBER to use.
(B) If you have code which you want to run as easily as possible, do you
consider the cost of locating the places which require this small change
from (MEMBER x y) to (MEMBER x y :TEST #'EQUAL) to be too much of a price
to pay for item A.
Keep in mind that this will likely not be the only incompatible change
proposed by Common Lisp, so if you're thinking about the binary question
of "Will my code run without my messing with it?" there is a fair chance
the answer will be no anyway.
∂20-Jun-83 0919 RPG Stallman
∂19-Jun-83 1832 FAHLMAN@CMU-CS-C Stallman
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 19 Jun 83 18:26:07 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 19 Jun 83 21:24:34 EDT
Date: Sun, 19 Jun 1983 21:24 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Dick Gabriel <RPG@SU-AI>
Subject: Stallman
In-reply-to: Msg of 19 Jun 83 1458 PDT from Dick Gabriel <RPG at SU-AI>
Dick,
The Stallman thing is more a matter of damage control than of seeing an
opportunity to win MIT people over to Common Lisp. Stallman felt that
his suggestions and complaints had been systematically excluded, and
that the MEMBER issue in particular was so critical to him that it HAD
to be reopened. The rational arguments were interspersed with assorted
threats about splitting from Common Lisp over this and even of writing
his own Common Lisp manual with everything done his way, thus sowing
confusion.
The right move at that point was probably to tell him that a freeze was
a freeze and it was just too bad if he hadn't heard about it. However,
that seemed sure to cause a split and I wasn't sure -- right then and
there on the phone -- whether this split would seriously screw everyone
at MIT who depended on the old Lisp Machines to get work done, so I
agreed to query the mailing list about MEMBER. (And also agreed to ask
a few of you about the funarg business.)
As it turns out, the Lisp Machine users have the option of using
Symbolics software, which will be compatible with Common Lisp, so I need
not have been quite so careful. With most people, getting a hearing in
the Common Lisp forum and then being voted down would at least leave
them with a feeling of having been treated fairly, but I somehow don't
think it's going to work that way this time. So it was probably a major
mistake trying to appease RMS. Oh, well, live and learn.
-- Scott
∂20-Jun-83 0920 RPG KMP's message
∂19-Jun-83 2024 @MIT-MC:RMS%MIT-OZ%MIT-MC@SU-DSN KMP's message
Received: from MIT-MC by SU-AI with TCP/SMTP; 19 Jun 83 20:24:13 PDT
Date: 19 Jun 1983 2318-EDT
From: RMS%MIT-OZ%MIT-MC@SU-DSN
Subject: KMP's message
To: info-lispm-mit%MIT-OZ%MIT-MC@SU-DSN
Please don't believe KMP's clarification of my question!
His facts are correct, but the question he clarified is not the one I asked.
Common Lisp has a nice set of sequence functions, with EQL the
default for the test. That is no problem for us, except:
some of them have the same names as familiar old Lisp functions
which they are incompatible with.
KMP has raised the issue of how those sequence functions ought to
work, and (it seems to me) supported the Common Lisp proposals. I
like them pretty well too, but that is a DIFFERENT ISSUE, which while
more interesting in itself has less impact on all our existing code.
It's also something that would require a much harder fight to change
(it's too late). So discuss that question if you want to, but don't
be distracted by it from the one that is just barely NOT too late:
Should certain function Common Lisp sequence functions,
which may be useful, avoid having names that are the same as
existing Lisp functions which they are not compatible with,
just so that our old code does not break.
-------
∂20-Jun-83 0920 RPG Destructuring &aux ?
∂19-Jun-83 2100 FAHLMAN@CMU-CS-C Destructuring &aux ?
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 19 Jun 83 20:59:56 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 19 Jun 83 23:58:20 EDT
Date: Sun, 19 Jun 1983 23:58 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: steele@CMU-CS-C
Cc: moon%scrc-tenex@mit-mc, dlw%scrc-tenex@mit-mc, rpg@su-ai
Subject: Destructuring &aux ?
A ballot or two ago, we decided that DEFMACRO would destructure its
arguments, and the decision was that a destructuring pattern could
appear "in any place where a variable symbol would be legal". I wonder
if we meant that to include &aux variables. I don't care much one way
or the other, but the manual should be clear on this (if it isn't too
late). I guess if it were up to me, I'd require &aux vars to be
symbols, on the grounds that if we allow destructuring here, we have in
effect sneaked a destructuring LET into the language. Some creative
undergrad will probably use it that way. However, it is a trivial
implementation tweak for me, so I'll go with whatever the manual says.
At one time we could have had &AUX and &aux, one destructuring and one not.
Unfortunately, the greater aux is extinct. (Sorry about that.)
-- Scott
∂20-Jun-83 0920 RPG Destructuring &aux ?
∂20-Jun-83 0814 @SU-SCORE.ARPA,@MIT-XX:Moon@SCRC-TENEX Destructuring &aux ?
Received: from SU-SCORE by SU-AI with TCP/SMTP; 20 Jun 83 08:14:17 PDT
Received: from MIT-XX by SU-SCORE.ARPA with TCP; Mon 20 Jun 83 08:15:42-PDT
Received: from SCRC-EUPHRATES by SCRC-SPANIEL with CHAOS; Mon 20-Jun-83 00:44:52-EDT
Date: Monday, 20 June 1983, 00:44-EDT
From: David A. Moon <Moon at SCRC-TENEX>
Subject: Destructuring &aux ?
To: Scott E. Fahlman <Fahlman at CMU-CS-C>
Cc: steele at CMU-CS-C, moon%scrc-tenex at MIT-MC,
dlw%scrc-tenex at MIT-MC, rpg at SU-AI
In-reply-to: The message of 19 Jun 83 23:58-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
I didn't intend to imply that aux variables should destructure. Sorry about the
loose wording (oops, burble, glub, there goes another ship!)
∂20-Jun-83 1422 @USC-ECL,@MIT-MC:BSG%SCRC-TENEX@MIT-MC keywordp
Received: from USC-ECL by SU-AI with TCP/SMTP; 20 Jun 83 14:21:31 PDT
Received: from MIT-MC by USC-ECL; Mon 20 Jun 83 14:18:32-PDT
Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Mon 20-Jun-83 17:17:47-EDT
Date: Monday, 20 June 1983, 17:14-EDT
From: Bernard S. Greenberg <BSG%SCRC-TENEX@MIT-MC>
Subject: keywordp
To: common-lisp%su-ai@USC-ECL
For the 1990 manual,...
Every time I have written (keywordp x), I have had to change it
to (and (symbolp x) (keywordp x)).
I suppose the profound observation is that keywords are more like numbers
than like symbols.
∂20-Jun-83 2030 RPG RMS's phone call
∂20-Jun-83 2018 Guy.Steele@CMU-CS-A RMS's phone call
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 20 Jun 83 20:17:45 PDT
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 20 Jun 83 23:11:24 EDT
Date: 20 Jun 83 2314 EDT (Monday)
From: Guy.Steele@CMU-CS-A
To: dlw@scrc-tenex@MIT-MC
Subject: RMS's phone call
CC: common-lisp-implementors@scrc-tenex@MIT-MC, rpg@SU-AI
I beg to differ on one minor comment concerning RMS's participation in
Common LISP meetings. I, for one, actively encouraged him to attend
all meetings possible for him. In particular, I urged him to come to
the August meeting at which the decision about MEMBER was made. If I
recall correctly, he thought that the financial resources for travel would
not be available to hm, which is possible. I was rather unhappy that he
was not able, for whatever reason, to attend. But he is on the standard
mailing list, and I am reasonably certain that I mailed to him copies
of all materials, electronic and paper, that were sent to everyone else,
including the ballot and meetings results, in timely fashion.
--Guy
I recall Guy asking RMS to attend last August's meeting. In fact, Guy and
I had several discussions concerning politics where the topic was
specifically LMI, Greenblatt, and RMS and their participation. We commented that
RMS was technically on target often enough to not ostracize him.
-rpg-
∂20-Jun-83 2032 RPG want to argue from experience?
∂20-Jun-83 2029 @MIT-MC:GJC%MIT-OZ%MIT-MC@SU-DSN want to argue from experience?
Received: from MIT-MC by SU-AI with TCP/SMTP; 20 Jun 83 20:25:55 PDT
Date: Mon, 20 Jun 1983 20:31 EDT
From: GJC%MIT-OZ%MIT-MC@SU-DSN
To: INFO-LISPM-MIT%MIT-OZ%MIT-MC@SU-DSN
Subject: want to argue from experience?
Those who would want to try out their code first hand to see what
"Common-Lisp" might do to it could use NIL on some of the local VAX's.
Other things such as incompatible "/" function and readtable have
interesting effects. You can also see what happens to numerical code
in cases which were previously errors, such as (SQRT -1) which now
returns #C(0.0 1.0), a complex number.
Another problem area is the changes to the semantics of property list
functions, which are unfortunately not completely specified!
As of now I am trying to track down some subtle Macsyma bugs (not causing
errors, just wrong results) which might be due to differences that I
did not predict beforehand. Its a lot of fun, really.
-gjc
p.s. EMACS remains the same!
∂20-Jun-83 2054 @MIT-MC:RMS%MIT-OZ%MIT-MC@SU-DSN
Received: from MIT-MC by SU-AI with TCP/SMTP; 20 Jun 83 20:53:56 PDT
Date: 20 Jun 1983 2351-EDT
From: RMS%MIT-OZ%MIT-MC@SU-DSN
To: common-lisp@SU-AI
I asked the user community specifically whether they would
rather see the new Common Lisp function named MEMBERP rather than MEMBER.
This is not a poll on the question of aesthetic improvement of
the language, such as might have been done last August
(but for which a poll of the user community as a whole is less relevant
than a poll of people interested in language design).
I find from this poll that about half the users strongly wish
to avoid a conversion, while the other half think it doesn't matter.
If this extrapolates to the users of all the hundred or so Lisp
machines in the world, that's a lot of users who would rather
avoid the conversion.
-------
∂20-Jun-83 2132 RPG RMS's Poll
To: "@CL.DIS[1,RPG]"@SU-AI
CC: "#COMMON.MSG[COM,LSP]"@SU-AI
When a poll reports a result totally different from the one expected a
priori, one is justified in calling into question the scientific validity
of that poll. Thus, I feel I must call RMS's methodology into question.
As I understand it he asked a question which is, briefly sketched, of the
form:
Given the choice, would you rather do some work, or would
you rather do *no* work?
That 50% of the people who responded stated they had no strong opinion
strikes me as totally bizarre. I would have expected 100% of the respondents
to state that they strongly preferred to do no work. Therefore, I suggest
we throw out the results of RMS's poll as being specious and revert to
our original decision to change MEMBER incompatibly.
-rpg-
∂21-Jun-83 1612 DLW@SCRC-TENEX OPEN for :OUTPUT with version :NEWEST
Received: from SU-DSN by SU-AI with PUP; 21-Jun-83 16:12 PDT
Received: From MIT-XX by SU-DSN.ARPA; Tue Jun 21 15:55:41 1983
Received: from SCRC-BORZOI by SCRC-SPANIEL with CHAOS; Tue 21-Jun-83 17:29:43-EDT
Date: Tuesday, 21 June 1983, 17:29-EDT
From: Daniel L. Weinreb <DLW at SCRC-TENEX>
Subject: OPEN for :OUTPUT with version :NEWEST
To: common-lisp at SU-AI
The following should be made clear by explicit mention somewhere in the manual:
Question: If you call OPEN, and the direction is :OUTPUT or :IO, and the
version of the file is :NEWEST, what version number is used?
Answer: If the :IF-EXISTS is :NEW-VERSION or unsupplied, then :NEWEST
in the pathname means "a version number one higher than the highest
version extant." In all other cases :NEWEST in the pathname means "the
highest extant version."
So if versions 1, 2, and 3 of a file exist, and you open the :NEWEST
version for :OUTPUT, then you get version 4 if the :IF-EXISTS is
:NEW-VERSION or unsupplied, but you get version 3 if the :IF-EXISTS is
anything else (e.g. :SUPERSEDE, :APPEND, :OVERWRITE, :RENAME, et al).
∂21-Jun-83 2221 FAHLMAN@CMU-CS-C Memberp
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 21 Jun 83 22:21:14 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 22 Jun 83 01:20:40 EDT
Date: Wed, 22 Jun 1983 01:20 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: rms%mit-oz@mit-mc, Common-Lisp@su-ai
Subject: Memberp
The comments that I have received on the MEMBERP issue indicate that,
with the exception of Chuck Hedrick (and RMS himself), none of the
people responsible for Common Lisp implementation efforts believe that
it is a good idea to adopt RMS's changes in MEMBER and friends. Three
different sets of reasons have been offered by the people responding:
1. People are not convinced that changing MEMBER to use EQL makes
substantially more trouble for RMS and his users than changing MEMBER to
MEMBERP would make for the rest of us, despite RMS's argument that we
could go on using our version of MEMBER.
2. The original reasons why we chose to make this change (regularity in
the choice of names leading to much less confusion in the long run) are
still valid.
3. Frozen is frozen. It's hard enough to get consensus without
reopening the debate every time someone wakes up and notices something
he doesn't like.
Even if we discount the opinions of the Symbolics people, who might be
imagined to have political reasons for opposing RMS in this, the clear
majority still seems to favor leaving the manual as it is, with MEMBER
using EQL. As far as I'm concerned, that's the end of it. I hope that
RMS will choose to remain compatible with Common Lisp despite this
decision, but that's up to him. All of us have had to make some major
compromises in the course of this effort, and so far everyone has stayed
aboard.
-- Scott
∂21-Jun-83 2250 @MIT-MC:RMS%MIT-OZ%MIT-MC@SU-DSN My poll of Lisp users
Received: from MIT-MC by SU-AI with TCP/SMTP; 21 Jun 83 22:50:15 PDT
Date: 22 Jun 1983 0146-EDT
From: RMS%MIT-OZ%MIT-MC@SU-DSN
Subject: My poll of Lisp users
To: common-lisp@SU-AI
I have forwarded Fahlman's message to all the Lispm users
and told them that I will let the MIT system users decide what
I should do with MEMBER.
Meanwhile, here are the answers I got.
From: JBA@MIT-OZ
Subject: Function MEMBER to be changed?
I agree with you that member shouldn't be changed.
From: ZVONA@MIT-OZ
Surely Common Lisp conversion will entail many other changes in code.
Why is this particular change important?
From: EB@MIT-OZ
I would prefer to see MEMBER use EQUAL for comparison, as now, because
I often use MEMBER on lists of lists.
From: DANNY@MIT-OZ
I agree with you.
From: Randy Davis <DAVIS@MIT-OZ>
let's hear it for upward compatibility; yes leave the names unchanged.
-------
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Since so many other things are going to break, I dont understand
why MEMBER is such a big deal.
From: Kent M. Pitman <KMP @ MIT-MC>
I vote yes for the change, as you probably already saw in my mail to
Common Lisp. I was originally somewhat worried about this change, but
having looked over my code, I find it actually breaks little or nothing.
I suspect other people responding might not realize how little effect
this will actually have.
I have for a long time discouraged people from using MEMBER, which is
the nicer name, when MEMQ would be more efficient. I think the name
change will be beneficial to code appearance because the new definition
of MEMBER is nearly always the appropriate one.
When the final Common Lisp document becomes available, I may try to write
some helpful facilities for translating existing code to Common Lisp,
probably in Teco. This is definitely one of those changes that could be made
relatively easily by such a program.
From: Jeffrey P. Golden <JPG @ MIT-MC>
If you are recording votes on the MEMBER etc. CL issue, I strongly
agree with your position on this. Not having been aware of the prior
discussion amongst CLers on this, when GJC mentioned to me on 6/14
what they were planning to do to MEMBER etc. I immediately responded:
'Horrors, why didn't they just call their version MEMBERP?' (Not exactly
in those words.)
From: Bruce R. Donald <BRD@MIT-OZ>
I use member a lot to check for "Yes" (and other strings) in a list of
menu choices. Also, (MEMBER VERTEX BOUNDARY) where BOUNDARY is a list
of vertices and VERTEX is a DEFSTRUCT of :type list would not work
with the common lisp MEMBER, no?
From: dove at mit-dspg
My personal code does not to my knowledge use member either for
lists as members or strings. Thus, the update problem should
not affect me. Besides, I have gotten somewhat used to changing
things to remain compatible.
From: KDF@MIT-OZ
To: dove@mit-dspg
I use MEMBER and ASSOC in cases where I really mean
EQUAL, and MEMQ and ASSQ when I really want EQ. Changing
MEMQ and ASSQ to use EQL seems reasonable, but such a change
to MEMBER and ASSOC clearly do not.
From: dove at mit-dspg
Given that member is often used on the lispm to check for strings in
things like menus, it seems that equal would be preferable. The
crux of the issue seems to be the simplification of that code (and the
ability to leave old code unmodified) versus speed.
From: Dick@MIT-MC
I agree that there is no reason to incompatibly change the meaning of
any function unless absolutely necessary. It sure doesn't seem
necesarry here.
Dick
-------
∂21-Jun-83 2259 RPG Unable to deliver mail
∂21-Jun-83 2021 @MIT-MC:CHAOS-MAILER@SCRC-VIXEN Unable to deliver mail
Received: from MIT-MC by SU-AI with TCP/SMTP; 21 Jun 83 20:21:17 PDT
Return-path: <CHAOS-MAILER@SCRC-VIXEN>
Received: from SCRC-VIXEN by SCRC-TENEX with CHAOS; Tue 21-Jun-83 17:38:59-EDT
Date: 21 Jun 1983 17:38:48-EDT
From: CHAOS-MAILER at scrc-vixen
To: DLW@SCRC-TENEX
Subject: Unable to deliver mail
Remailed-date: 21 Jun 1983 2320-EDT
Remailed-from: Daniel L. Weinreb <DLW%SCRC-TENEX%MIT-MC@SU-DSN>
Remailed-to: rpg@SU-AI
A message to host 'su-ai' could not be sent.
The reason is: -Unknown destination host: su-ai
---The text of the message follows---
Received: from scrc-borzoi by scrc-vixen with CHAOS; 21 Jun 1983 17:25:35-EDT
Date: Tuesday, 21 June 1983, 17:22-EDT
From: Daniel L. Weinreb <DLW at SCRC-TENEX>
Subject: Broken host table on a mailer, try again.
To: rpg at SU-AI
Date: Tuesday, 21 June 1983, 10:49-EDT
From: Daniel L. Weinreb <DLW at SCRC-TENEX>
Subject: RMS's phone call
To: Guy.Steele at CMU-CS-A
Cc: common-lisp-implementors at SCRC-TENEX, rpg at SU-AI,
fahlman at CMU-CS-C
In-reply-to: The message of 20 Jun 83 23:14-EDT from Guy.Steele at CMU-CS-A
I see, I hadn't understood that. Well, in that case, it's more his own
fault that he didn't mention the MEMBER change earlier, so I don't feel
as bad about saying what I did.
By the way, someone might ask him what the sample size of his poll was,
although maybe that would be giving it too much credit.
∂21-Jun-83 2259 RPG Common LISP Nonsense
∂21-Jun-83 1651 @MIT-MC:JBA%MIT-OZ%MIT-MC@SU-DSN Common LISP Nonsense
Received: from MIT-MC by SU-AI with TCP/SMTP; 21 Jun 83 16:51:14 PDT
Date: Tuesday, 21 June 1983, 19:42-EDT
From: Jon Amsterdam <JBA%MIT-OZ%MIT-MC@SU-DSN>
Subject: Common LISP Nonsense
To: GLR%MIT-OZ%MIT-MC@SU-DSN, INFO-LISPM-MIT%MIT-OZ%MIT-MC@SU-DSN
In-reply-to: The message of 21 Jun 83 10:59-EDT from Jerry Roylance <GLR at MIT-OZ>
Return-path: <GLR@MIT-OZ>
Mail-From: GLR created at 21-Jun-83 10:59:48
Date: Tue, 21 Jun 1983 10:59 EDT
From: Jerry Roylance <GLR@MIT-OZ>
To: INFO-LISPM-MIT@MIT-OZ
Subject: Common LISP Nonsense
In-reply-to: Msg of 20 Jun 1983 20:31-EDT from GJC
This mailing list is not the proper forum.
Where then? Since I guess common lisp is going to be more and more a
topic of discussion around here, how about "common-lisp-forum"
or "common-lisp-flames" or something like that?
∂21-Jun-83 2320 RPG Common Lisp
To: common-lisp@SU-AI
There is a price and a benefit in seeking to make a new standard language.
Being a new standard it can afford to regularize those features of the
language that have been recognized as useful. A language like Lisp can
grow by adding features pell-mell. The benefit is that when we re-make it
we can improve it, though we may alter unimportant parts of the language
that are part of its tradition. The price is to give up some habits and
familiar paths of programming.
When some group decides to implement ``Common Lisp'' except for those some
features they like from an older Lisp, then that community has adopted a
Common-Lisp-like Lisp. The Lisp they run is not Common Lisp; none of the
guarantees of compatibility are extended to them: they must bear the
brunt of modifying their code to run on other Common Lisps; and they must
re-write other people's code to run on their Lisp.
This is their choice.
The idea behind a standard is that it is a standard.
-rpg-
∂22-Jun-83 0015 RPG Manual
To: steele@CMU-CS-C, fahlman@CMU-CS-C
CC: "#COMMON.MSG[COM,LSP]"@SU-AI
Speaking of real work: Guy, you ought to make sure that the manual is
clear on several points (or specifically unclear) - the behavior of closures.
Let x be a variable free in the lambda-expression that defines a closure.
If x is setq'ed after the closure is made, does the closure reflect the
update?
Consider:
(let ((x ...))
(do ((a ())) ...
(push (lambda (..)...x) a)))
Does A contain a list of EQ closures?
What about this?
(let ((x ...))
(do ((a ())) ...
(setq x ...)
(push (lambda (..)...x) a)))
And this?
(do ((a ())) ...
(let ((x ...))
(push (lambda (..)...x) a)))
My answers are: Yes, setq changes the value in the first example. In the
second the closures are the same, and they may be EQ (logically performed
at the LAMBDA). In the third example they are the same, and they may be EQ.
In the last they are not EQ and not the same.
-rpg-
∂22-Jun-83 0045 FAHLMAN@CMU-CS-C MEMBER
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 22 Jun 83 00:44:57 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 22 Jun 83 03:44:05 EDT
Date: Wed, 22 Jun 1983 03:44 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: info-lispm-mit%mit-oz@mit-mc
Cc: common-lisp@su-ai
Subject: MEMBER
Recently RMS polled asked the opinion of people on this list about the
plan to change the definition of MEMBER in Common Lisp. Some of the
responses indicated some confusion as to what we (the people who have
been working for the last two years to hammer out a Common Lisp
definition) are actually proposing. I would like to clarify this before
too many people get too upset.
For a long time, Lisp has had EQUAL and EQ versions of some of the
important operators: MEMBER/MEMQ, DELETE/DELQ, etc. Modern lisps have a
lot more data types and a lot more specialized equality predicates: EQL,
=, STRING=, etc. Things began to multiply. At one point, we had some
600 of these sequence functions, including such gems as RASS-EQL and
DEL-FROM-END-IF-NOT. The decision was made to to cut this number down
by providing a small number of powerful generic functions that could be
further specialized by the use of keywords. These generic functions
were uniformly given the "good" names. Thus we have operators like
REPLACE, REMOVE, POSITION, and MEMBER, each of which takes a :TEST
keyword telling what sort of equality test to use. In all cases, the
default test is EQL, by far the most useful. (Though they are
redundant, we kept around MEMQ, DELQ, and ASSQ as historical monuments.)
So, if you want something that does what (MEMBER x y) does in Maclisp,
you have to say (MEMBER x y :TEST #'EQUAL) in Common Lisp. We
considered many alternatives to this scheme: making EQUAL the universal
default, having MEMBER default to EQUAL while the other functions
default to EQL, or thinking up a new name for the function that does
what MEMBER does. In the end, we decided to do what I described above.
It seemed clear to us that this would be best in the long run, after
everyone has forgotten the details of earlier Lisps, and it seemed like
an easy (mechanizable) conversion to put the :TEST 'EQUAL into every
MEMBER call in a file.
I'm sure that many people will disagree with this choice, but it was not
a frivolous or hasty decision; a lot of experienced Lisp implementors
agonized for a long time over this one, and finally reached an agreement
acceptable to all those participating in the Common Lisp design at that
time. That is why we are reluctant to re-open the debate nine-months
later, only days before the Common Lisp manual goes to press.
-- Scott Fahlman
∂22-Jun-83 0059 KMP@MIT-MC OPEN for :OUTPUT with version :NEWEST
Received: from MIT-MC by SU-AI with TCP/SMTP; 22 Jun 83 00:59:30 PDT
Date: 22 June 1983 03:54 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
Subject: OPEN for :OUTPUT with version :NEWEST
To: DLW @ SCRC-TENEX
cc: common-lisp @ SU-AI
In-reply-to: Msg of 21 Jun 1983 17:29-EDT from Daniel L. Weinreb <DLW at SCRC-TENEX>
Date: Tuesday, 21 June 1983, 17:29-EDT
From: Daniel L. Weinreb <DLW at SCRC-TENEX>
The following should be made clear by explicit mention somewhere in
the manual:
Question: If you call OPEN, and the direction is :OUTPUT or :IO, and the
version of the file is :NEWEST, what version number is used?
Answer: If the :IF-EXISTS is :NEW-VERSION or unsupplied, then :NEWEST
in the pathname means "a version number one higher than the highest
version extant." In all other cases :NEWEST in the pathname means "the
highest extant version."
So if versions 1, 2, and 3 of a file exist, and you open the :NEWEST
version for :OUTPUT, then you get version 4 if the :IF-EXISTS is
:NEW-VERSION or unsupplied, but you get version 3 if the :IF-EXISTS is
anything else (e.g. :SUPERSEDE, :APPEND, :OVERWRITE, :RENAME, et al).
Perhaps I'm confused, but isn't it the job of the operating system to decide
what the actual filename is? Must the language spec specify "one higher" or
should it just say "newer" or "higher". It seems to me like this wouldn't
mean any hardship for the users of CL and might make it easier for
implementors of some CL systems depending on how the operating system they
had treated version numbers (eg, some operating system might not assign a
version until the CLOSE happened).
My worry here is that we be careful about not defining detail where it's
not necessary. I'm not arguing that my position as presented here is right;
just requesting commentary/clarification of your intent.
--kmp
∂22-Jun-83 0347 @MIT-MC:DLW%SCRC-TENEX%MIT-MC@SU-DSN Re: OPEN for :OUTPUT with version :NEWEST
Received: from MIT-MC by SU-AI with TCP/SMTP; 22 Jun 83 03:47:39 PDT
Date: 22 Jun 1983 0646-EDT
From: Daniel L. Weinreb <DLW%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Re: OPEN for :OUTPUT with version :NEWEST
To: KMP%MIT-MC@SU-DSN
cc: common-lisp@SU-AI
In-Reply-To: The message of 22 June 1983 03:54 EDT from Kent M. Pitman <KMP @ MIT-MC>
The intent of my clarification is simple: without that clarification, some
of the OPEN options are meaningless or incomprehensible. If someone asks
you "what happens if you OPEN for output with version :NEWEST and :IF-EXISTS
:SUPERSEDE, does it use the existing latets file or create a new one?", it's
unacceptable to just say "Well, it depends on the implementation, we wouldn't
want to constrain any implementation to do any particular thing."
Common Lisp's file model already includes the concept of versions, so
we're not adding anything new. I'm not trying to overspecify how versions
precisely work. The only distinction I'm drawing is between the two
meanings that :newest can have (the input meaning and the output
meaning, latest version or create new version), and pointing out that
:IF-EXISTS controls which one of those happens, which was
not at all obvious to me from the manual (Moon had to figure out that
such was the implication of the manual).
-------
∂22-Jun-83 0430 RAM@CMU-CS-C OPEN for :OUTPUT with version :NEWEST
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 22 Jun 83 04:29:22 PDT
Received: ID <RAM@CMU-CS-C>; 22 Jun 83 07:28:13 EDT
Date: Wed, 22 Jun 1983 07:28 EDT
From: Rob MacLachlan <RAM@CMU-CS-C>
To: Daniel L. Weinreb <DLW%SCRC-TENEX%MIT-MC@SU-DSN>
Cc: common-lisp@SU-AI, KMP%MIT-MC@SU-DSN
Subject: OPEN for :OUTPUT with version :NEWEST
In-reply-to: Msg of 22 Jun 1983 06:46-EDT from Daniel L. Weinreb <DLW%SCRC-TENEX%MIT-MC at SU-DSN>
I would agree that some clarification is called for. I have been
in the position of having to write implementation independant file
handling code for the Hemlock text editor I am working on, and I have
had some difficulty. In the DEC VAX implementation I have been using,
the implementer evidently decided that if an explicit version is
specified then an attempt to open for write will error, not supersede,
regardless of the :if-exists option. Perhaps this is wrong, but the
manual is not very clear on this point.
Another point about versions; not all operating systems have any
real concept of versions. It would seem dubious to forbid an
implementation of Common Lisp on UNIX.
It seems to me that the entire point of Pathnames is that they (may)
permit implementation independant file handling code to be written.
Implementers should be given plenty of rope, but it should be possible
to say something as simple as "I want to write this file" in a
portable fashion, or the whole exercise is pointless.
Rob
∂22-Jun-83 0828 RZ@MIT-MC Rational and complex numbers
Received: from MIT-MC by SU-AI with TCP/SMTP; 22 Jun 83 08:28:13 PDT
Date: 22 June 1983 11:28 EDT
From: Richard E. Zippel <RZ @ MIT-MC>
Subject: Rational and complex numbers
To: Guy.Steele @ CMU-CS-A
cc: common-lisp @ SU-AI
In-reply-to: Msg of 12 Jun 83 2346 EDT () from Guy.Steele at CMU-CS-A
Date: 12 Jun 83 2346 EDT (Sunday)
From: Guy.Steele at CMU-CS-A
To: Richard E. Zippel <RZ>
cc: common-lisp at SU-AI
Re: Rational and complex numbers
I do foresee one entirely plausible application for Gaussian integers,
which is graphics applications. For discrete bit-map representations,
Gaussian integers may be a very convenient representation. Some interesting
work has been done at Yale on picture languages that use complex numbers.
I also admit once again to harboring the secret ambition for some form
of LISP to supplant FORTRAN...
--Guy
Another version of this would use an arbitrary two dimensional module
instead of the complex numbers. For instance I suspect that if you
associate the point (a, b) into a + sqrt(-163)*b, and then plot the powers
of (1+ sqrt(-163)) you will get some interesting results. Similarly, taking
a some image and then multiplying it by a complex number can lead to
interesting versions of scaling. Finally, the wrap around types of windows
we used in Space War might be best represented as GF(1031)[x]/(x↑2+1) or
something (actually GF(1024)xGF(1024) would be more natural).
∂22-Jun-83 0839 @MIT-MC:DLW%SCRC-TENEX%MIT-MC@SU-DSN OPEN for :OUTPUT with version :NEWEST
Received: from MIT-MC by SU-AI with TCP/SMTP; 22 Jun 83 08:36:45 PDT
Received: from SCRC-BORZOI by SCRC-TENEX with CHAOS; Wed 22-Jun-83 11:29:35-EDT
Date: Wednesday, 22 June 1983, 11:27-EDT
From: Daniel L. Weinreb <DLW%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: OPEN for :OUTPUT with version :NEWEST
To: RAM%CMU-CS-C@SU-DSN
Cc: common-lisp@SU-AI
In-reply-to: The message of 22 Jun 83 07:28-EDT from Rob MacLachlan <RAM at CMU-CS-C>
Date: Wed, 22 Jun 1983 07:28 EDT
From: Rob MacLachlan <RAM@CMU-CS-C>
In the DEC VAX implementation I have been using,
the implementer evidently decided that if an explicit version is
specified then an attempt to open for write will error, not supersede,
regardless of the :if-exists option. Perhaps this is wrong, but the
manual is not very clear on this point.
It's definitely wrong, and I think it's clear from the manual that it's
wrong, although the manual isn't completely clear about a lot of details
of this stuff.
It seems to me that the entire point of Pathnames is that they (may)
permit implementation independant file handling code to be written.
Implementers should be given plenty of rope, but it should be possible
to say something as simple as "I want to write this file" in a
portable fashion, or the whole exercise is pointless.
Certainly. That's why I sent in my previous message. There has to
be a defined way for all this stuff to work, or else it's useless for
writing portable programs and should be removed from the manual. I
think the former is the way to go.
Another point about versions; not all operating systems have any
real concept of versions. It would seem dubious to forbid an
implementation of Common Lisp on UNIX.
That's right; the manual ought to address this point. Actually, I think
what will happen is that now that the Bible of Common Lisp is nearly
finished, it is time to start writing the Talmud, you should pardon the
analogy. That is, the Commentary and Interpretation by the Learned
Rabbis of Common Lisp. The commentary on this chapter would say
that in Rabbi Weinreb's opinion, the meaning of the scriptures is
that on operating systems without version numbers, you simply ignore
the version component of pathnames when doing an OPEN, and acts as
if every pathname had an explicit numeric version of, say, 1, and all
files in the file system are of version 1. This is what the Lisp
Machine pathname system does, essentially.
∂22-Jun-83 1429 RPG Common Lisp support
∂22-Jun-83 1356 @MIT-MC:RMS%MIT-OZ%MIT-MC@SU-DSN Common Lisp support
Received: from MIT-MC by SU-AI with TCP/SMTP; 22 Jun 83 13:55:36 PDT
Date: 22 Jun 1983 1642-EDT
From: RMS%MIT-OZ%MIT-MC@SU-DSN
Subject: Common Lisp support
To: info-lispm-mit%MIT-OZ%MIT-MC@SU-DSN
I am now investigating ways to put all of the Common Lisp incompatibilities
into an optional mode which users could specify on a per-file basis.
This would allow users to convert only if they wish to.
I think I can arrange for nearly all incompatibilities to be
optional in this way.
-------
∂22-Jun-83 2310 HEDRICK@RUTGERS.ARPA Re: Memberp
Received: from RUTGERS by SU-AI with TCP/SMTP; 22 Jun 83 23:10:33 PDT
Date: 23 Jun 83 02:10:24 EDT
From: Dir LCSR Comp Facility <HEDRICK@RUTGERS.ARPA>
Subject: Re: Memberp
To: Fahlman@CMU-CS-C.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: Message from "Scott E. Fahlman <Fahlman@CMU-CS-C>" of 22 Jun 83 01:20:00 EDT
Don't take me too seriously. Remember that my comment was simply on the
general grounds that we should stick as close to Lisp 1.5 as possible.
There is no reason to pay any more attention to my opinion on this
issue than in the 1587 other places where incompatibilities have been
introduced over my protests. Frankly, I am inclined to agree with the
LISPM users who responded, "after completely redesigning the language,
why is everybody so upset about MEMBER?" Reminds me of straining out
gnats while swallowing camels. Personally I don't want to swallow
either gnats or camels, and you can expect to hear protests from me as a
matter of principle whenever you deviate from Lisp 1.5. But Common Lisp
seems to be commited to swallowing 2 camels, 3 hippopotami, and assorted
small alligators. (It is my opinion that at this point the dreaded
stacus spaghetticus dwimus could enter and no one would even notice.) So
I don't see any reason to reopen things over MEMBER.
-------
∂23-Jun-83 1110 RPG Re: Clarification of closures
∂22-Jun-83 2122 Guy.Steele@CMU-CS-A Re: Clarification of closures
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 22 Jun 83 21:22:25 PDT
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 22 Jun 83 22:57:26 EDT
Date: 22 Jun 83 2302 EDT (Wednesday)
From: Guy.Steele@CMU-CS-A
To: Dick Gabriel <RPG@SU-AI>
Subject: Re: Clarification of closures
CC: Scott.Fahlman <FAHLMAN@CMU-CS-C>
In-Reply-To: "Dick Gabriel's message of 22 Jun 83 11:15-EST"
Well, I certainly was confused.
HOW CONFUSED WERE YOU?
Why, I was so confused, I thought a square knot was the speed of a raft!
Why, I was so confused, I thought Soupy Sales was a price cut on Campbell's!
Why, I was so confused, I thought that the Gallup Poll was the Warsaw cavalry!
Yuk yuk yuk!
(APPLAUSE)
But seriously, folks...
Now that I understand which answers correspond to which questions, I find
that I agree with all your answers. I have always thought of (lambda () ...)
as being a kind of conser, but you have shed new light on the subject.
You are quite correct that there is no a priori reason, from semantical
considerations, to require two executions of (lambda () ...) to produce
EQ-disjoint objects in your examples 2 and 3. I wish I had thought of that!
It clearly follows from the principle Sussman and I got so excited about
in "The Art of the Interpreter": the more things change, the more they
remain the same. So if two closures can only detect differences between
them by whether or not they share the same set of bindings, then if they
share the same set of bindings they might as well be EQ. For pragmatic
reasons I suppose in Common LISP we should give the implementor the
choice. Should EQL report that two closures are the same if they share
the same code and the same set of bindings?
--Q
Guy and Scott, here is a rambling essay on closures and why I don't think
we should say anything about EQLness of closures in this edition:
I think we ought not state EQL behavior on closures yet. I'm not confident
that all implementations can easily extend EQL to this case, and I think
most people will expect EQL to be `fast.' To understand why I am not
confident, here's what the S-1 (will be)/(is) doing:
If `the same' closures do not need to be EQ-disjoint, then in the S-1
implemenation, I intend to make all such closures EQ, since closure
copying will be relatively expensive (a vector-copy). The way I will
accomplish this is to move all closure-creations up to the lowest
lambda-node enclosing the lambda-expression that defines the closure and
which binds a variable the closure captures. I believe this handles the
examples I mentioned in my misleading message of answers and questions.
I think that stating the behavior of EQL on closures to be as Guy
stated means that all implementations must perform the lowest-lambda
analysis in the compiler and interpreter. Perhaps this is too much to
ask---it is too specific a behavior of the implementation.
Once we state that EQL must behave sensibly, hacks to further improve
closure speed may render EQL difficult. Here is a half-baked example
of that, but which is along lines I am pursuing at the moment:
Consider `trivial' closures---for instance, ones that appear
in LABELS, and are simply used to define functions and run them. A better
characterization is that they are closures that are never returned as
values, are never (really) created repeatedly in loops, and which never
are passed as arguments to non-lexically-apparent functions. For these,
I'd like to CONS them once - at load time. Guy's example on page 75 of the
Laser edition is good, but even if the functions in the LABELS were to
close over some variables, these closures can be created once at load-time,
and their bindings could be updated on each entry to the appropriate LAMBDA.
Now, I imagine that I cannot write an analysis routine that will guarantee
to locate exactly these cases correctly. To preserve correctness, I must
be conservative, and therefore I must actually CONS in cases where I might
not be required to CONS.
The upshot is that if I were to know that EQL closures were actually
EQ, then extending EQL to closures is trivial. I would know this is if
my analysis routines could decide every function. But since I don't think
such analysis routines can be written, I must CONS, and maybe I must
needlessly CONS. So, I will be making closures that are EQL, but which
are not EQ.
Therefore, in the S-1 implementation, extending EQL to closures would
mean, pretty much, that EQL would have a do a vector-equal, cut off at the
element level, to test closures. That is, two closures would be EQL if
the vectors representing each had elements where each pair were EQL (or
maybe just if some specific pairs were EQL).
Here are some more examples:
(do ((a ()))
(<test> a)
(push (FOO) a))
(defun foo () (lambda (q)...))
Does this produce a list of EQ elements? I don't know the anwswer, but
I suspect that referential transparency means that the lowest lambda
that binds a variable captured in the closure can be considered to
be above the DO, and so the method I mentioned above for deciding when
to CONS implies that these closures are EQ.
Here's another:
(do ((a ())
(b ...))
(<test> a)
(push (FOO b) a))
(defun foo (x) (lambda (q)...x...))
This must produce an EQ-disjoint list, and the test above implies that.
∂23-Jun-83 1453 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN [RZ at MC: Rational and complex numbers]
Received: from MIT-MC by SU-AI with TCP/SMTP; 23 Jun 83 14:52:45 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Thu 23-Jun-83 17:49:46-EDT
Date: Thursday, 23 June 1983, 17:51-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: [RZ at MC: Rational and complex numbers]
To: common-lisp@SU-AI
Cc: rz%MIT-MC@SU-DSN
Here's a clarification from Rich Zippel of his feelings about rational
and complex numbers. I am simply forwarding this to the group for
informational purposes; I am not advocating doing anything about it
at this time. My feeling is that he is talking at a much higher level
than the Common Lisp language deals with. A system for modeling
general rings, fields, and other algebras would be a valuable thing to
have, but has little to do with the implementation of ordinary arithmetic in Lisp
except that the ordinary numbers would be a subset of the data types in
which the algebra system would deal. Then we must address the question
of whether rational numbers are valuable enough in their own right (rather than
as one particular algebra) that they belong in the language. The impression
I get is that a number of people have felt that they would far rather use
rational numbers than floating-point numbers for certain kinds of computations
(e.g. IC layout).
Date: Wednesday, 22 June 1983, 14:08-EDT
From: Richard E. Zippel <RZ at MIT-MC>
Subject: Rational and complex numbers
To: Carl W. Hoffman <CWH at SCRC-TENEX>
Cc: Moon at SCRC-TENEX, rz at mit-mc
Your second message on this topic completed what you said in your first
message. I think you should have sent them both together. Were you really
trying to say that the design of rationals as proposed for Common Lisp should
not be used, or that better designs were possible? Why don't you make an
alternate proposal?
What I was trying to say, was that the current design of rationals in Common
Lisp is inadequate and not sufficiently visionary. I personally think that
not having a rational number system in Common Lisp is better than having one
which will have to be removed at some later date when we understand the
problem more fully. In particular I am afraid that we won't produce a new
system, or will resist the introduction of such a system because of the
investment that had been made in the current system.
Making a good alternate proposal is a major research undertaking. Let
me mention some of the issues and some ideas that should be pursued.
You are trying to allow users to use algebraic structures based on the
integers. There are three issues here:
(1) Creation of algrebaic types
(2) The gathering together of the appropriate algorithms/code for
different types created by the user
(3) A theory of coercion.
(1) Creation of algebraic types:
There are several mechanisms that might be used to create new
structures. The following list some of the most important that should be
provided by the system.
(a) quotient structures: This is how rational numbers are constructed.
The numerators and denominators need not come from the same domain, but
the denominators must be a subset of the numerators. This allows you to
deal with localization, farey sequenced and other mathematical
structures.
(b) Polynomials: You might think that adding algebraic numbers would be
the next construction mechanism, but it is best to build it on top of
polynomials. The coefficients must be the elements of some algebraic
structure, the exponents are integers.
(c) Modular structures. Some domain, were an element different from
zero is now assumed to be zero. E.g., integers mod 5, gaussian
integers. The guassian integers are polyonomials in X where we have
assumed X↑2 + 1 is zero. This allows more complex structures like
algebraic functions.
(d) Matrices, vector spaces, etc.
With these constructors most interesting mathematic data structures can
be built.
(2) Getting the code together.
Now that you can build arbitrarily complex structures you are faced with the
problem of making sure the right algorithm is associated with a
particular operation. This is one of the purposes of the Capsule paper.
It describes some mechanisms that allow the creation of an algebraic
structure to control the particular algorithms that are used for
operations like plus and times. I could go into more detail here later
if its interesting.
(3) Coercion
Coercion is the process of make semantic identification of an abstract
mathematical object. Let describe what I've been calling a
``computational structure'' which is one way to deal with some of the
problems of coercion. Computational structures consist of a set of
domains which are in use (Z and Q are examples, there may be several Z's
and Q's), and maps between the these domains. There may be more than
one map between two domains. Certain of these maps are labeled as being
canonical maps. When an operation like (+ A B) occurs, the following
things happen: If A and B come from the same domain, then the +
operation of that domain is used (that's the easy case, and the only one
I believe should be implemented in Common Lisp now). If A and B are of
different domains, then these two domains are located in the
computational structure, and the canonical maps are followed to find a
domain in which both elements can be considered. These elements are
coerced into this new domain using the canonical maps, and the the
operation is executed in the new domain. Notice that the new domain
need not be the domain of A or B but can be a third domain.
There are a lot of complications with the scheme just described, but
some variation of it is probably OK.
This should give you some idea the issues I'm worried about. [For Dave:
Carl and I have spoken about this to some length already, so he can
probably fill in many of the details.]
It seems to me that you are asking for ways to represent 3*pi, 3*sqrt(2),
etc., and, when divided by 4, have these yield (3/4)*pi, (3/4)*sqrt(2), etc.
I would say that this has more to do with representing all of R (or with
representing extensions of Z) than with the injections of Z into Q.
Even if no changes are made to the current design (which is what I expect will
happen), don't you feel that the advantages of having simple-minded rationals
available in Common Lisp will outweigh the disadvantages? You don't have to
use them if you don't want to.
If you think this is clear enough and worth saving you might want to
forward this to Common-Lisp.
∂24-Jun-83 0809 RZ@MIT-MC [RZ at MC: Rational and complex numbers]
Received: from MIT-MC by SU-AI with TCP/SMTP; 24 Jun 83 08:08:51 PDT
Date: 24 June 1983 11:08 EDT
From: Richard E. Zippel <RZ @ MIT-MC>
Subject: [RZ at MC: Rational and complex numbers]
To: Moon @ SCRC-TENEX
cc: common-lisp @ SU-AI
In-reply-to: Msg of 23 Jun 1983 17:51-EDT from David A. Moon <Moon at SCRC-TENEX>
THought it would be useful to mention that these comments I've been sending
on numeric issues are really intended more for the 1990 version of Common
Lisp than the one that has been frozen. My purpose in sending them was to
get them into the record and give people something to think about.
∂25-Jun-83 0922 FAHLMAN@CMU-CS-C &whole
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 25 Jun 83 09:21:58 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 25 Jun 83 12:21:33 EDT
Date: Sat, 25 Jun 1983 12:21 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: steele@CMU-CS-C
Cc: common-lisp@su-ai
Subject: &whole
The manual currently is a bit hazy on where in a defmacro arglist the
&whole keyword is legal. I'm assuming anywhere except after &key or
&aux. All uses of this that I have seen are stand-alone, but there's no
strong reason for the restriction.
-- Scott
∂25-Jun-83 1812 RPG Closures
To: fahlman@CMU-CS-C, steele@CMU-CS-C
CC: "#COMMON.MSG[COM,LSP]"@SU-AI
I agree that we ought to leave closure-EQness optional behavior,
but I do think that the possibility of it must be noted in the manual.
When Rees, Fahlman, Steele, and Gabriel are a bit puzzled by the issues
and have to think about what the behaviors can be, I think that it
deserves some discussion in the manual.
-rpg-
∂29-Jun-83 1033 RPG Okay, guys, this is serious
∂27-Jun-83 2052 Guy.Steele@CMU-CS-A Okay, guys, this is serious
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 27 Jun 83 20:52:05 PDT
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 27 Jun 83 23:42:53 EDT
Date: 27 Jun 83 2346 EDT (Monday)
From: Guy.Steele@CMU-CS-A
To: moon%scrc-tenex@MIT-MC, dlw%scrc-tenex@MIT-MC,
Scott.Fahlman <FAHLMAN@CMU-CS-C>, rpg@SU-AI
Subject: Okay, guys, this is serious
What do we do about THIS?
(My vote is to replace infix "#:" with "::". Second favorite is
to require the "|#" that closes a "#|" comment to be followed by
whitespace.)
--Guy
- - - - Begin forwarded message - - - -
Received: from CMU-CS-PT by CMU-CS-A; 27 Jun 83 14:36:05 EDT
Received: from CMU-CS-C by CMU-CS-PT; 27 Jun 83 14:31:01 EDT
Received: ID <LES@CMU-CS-C>; 27 Jun 83 14:34:58 EDT
Date: 27 Jun 83 14:34:58 EDT
From: LES@CMU-CS-C
Subject: #|
To: steeLE@CMU-CS-C
The comment syntax #| has a problem in that there is no obvious way
to distinguish close comments (|#) from |foo|#:symbol. Scott says
to leave it alone and screw the luser. Dill says it's my civic duty
to complain about such lossage. Any comments ?
-------
- - - - End forwarded message - - - -
∂27-Jun-83 2201 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN Okay, guys, this is serious
Received: from MIT-MC by SU-AI with TCP/SMTP; 27 Jun 83 22:01:03 PDT
Received: from SCRC-BORZOI by SCRC-TENEX with CHAOS; Tue 28-Jun-83 01:01:07-EDT
Date: Tuesday, 28 June 1983, 00:59-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Okay, guys, this is serious
To: Guy.Steele%CMU-CS-A@SU-DSN
Cc: moon%SCRC-TENEX%MIT-MC@SU-DSN, dlw%SCRC-TENEX%MIT-MC@SU-DSN,
Scott.Fahlman <FAHLMAN%CMU-CS-C@SU-DSN>, rpg@SU-AI
In-reply-to: The message of 27 Jun 83 23:46-EDT from Guy.Steele at CMU-CS-A
Here are my suggestions, most preferable first:
1. Flush vertical bars around package prefixes
2. Require |# to be followed by whitespace
3. Switch #: to :: (only the infix case, or the uninterned symbol case too?)
I can live with #3, although I don't like it because we may want that
syntax for something else.
Two related facts (not complaints, just facts):
Typing in |Foo| at the Lisp top-level loop now requires you to type
a delimiter after the closing vertical bar, when it didn't before.
In our reader, typing |Foo|#' causes an error rather than reading
as a symbol followed by a sharpsign-quote macro. I can't see any way around
this (we are committed to one-character lookahead between expressions). The
reader of vertical bars has to read the quote before it knows it isn't
reading a package prefix.
∂29-Jun-83 1035 RPG Re: Clarification of closures
∂24-Jun-83 2134 Guy.Steele@CMU-CS-A Re: Clarification of closures
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 24 Jun 83 21:33:56 PDT
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 25 Jun 83 00:25:04 EDT
Date: 25 Jun 83 0029 EDT (Saturday)
From: Guy.Steele@CMU-CS-A
To: Scott E. Fahlman <Fahlman@CMU-CS-C>
Subject: Re: Clarification of closures
CC: rpg@SU-AI
In-Reply-To: "Scott E. Fahlman's message of 22 Jun 83 22:35-EST"
No, I was quite serious about EQL, but I am even more serious about
the language being frozen. I think that closure EQ-ness in RPG's
examples should be permitted but not required, and perhaps we should
simply be silent about closures and EQL for now.
--Guy
∂29-Jun-83 1036 RPG Re: Clarification of closures
∂22-Jun-83 2122 Guy.Steele@CMU-CS-A Re: Clarification of closures
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 22 Jun 83 21:22:25 PDT
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 22 Jun 83 22:57:26 EDT
Date: 22 Jun 83 2302 EDT (Wednesday)
From: Guy.Steele@CMU-CS-A
To: Dick Gabriel <RPG@SU-AI>
Subject: Re: Clarification of closures
CC: Scott.Fahlman <FAHLMAN@CMU-CS-C>
In-Reply-To: "Dick Gabriel's message of 22 Jun 83 11:15-EST"
Well, I certainly was confused.
HOW CONFUSED WERE YOU?
Why, I was so confused, I thought a square knot was the speed of a raft!
Why, I was so confused, I thought Soupy Sales was a price cut on Campbell's!
Why, I was so confused, I thought that the Gallup Poll was the Warsaw cavalry!
Yuk yuk yuk!
(APPLAUSE)
But seriously, folks...
Now that I understand which answers correspond to which questions, I find
that I agree with all your answers. I have always thought of (lambda () ...)
as being a kind of conser, but you have shed new light on the subject.
You are quite correct that there is no a priori reason, from semantical
considerations, to require two executions of (lambda () ...) to produce
EQ-disjoint objects in your examples 2 and 3. I wish I had thought of that!
It clearly follows from the principle Sussman and I got so excited about
in "The Art of the Interpreter": the more things change, the more they
remain the same. So if two closures can only detect differences between
them by whether or not they share the same set of bindings, then if they
share the same set of bindings they might as well be EQ. For pragmatic
reasons I suppose in Common LISP we should give the implementor the
choice. Should EQL report that two closures are the same if they share
the same code and the same set of bindings?
--Q
Closure Cloture
Guy and Scott, here is a rambling essay on closures and why I don't think
we should say anything about EQLness of closures in this edition:
I think we ought not state EQL behavior on closures yet. I'm not confident
that all implementations can easily extend EQL to this case, and I think
most people will expect EQL to be `fast.' To understand why I am not
confident, here's what the S-1 (will be)/(is) doing:
If `the same' closures do not need to be EQ-disjoint, then in the S-1
implemenation, I intend to make all such closures EQ, since closure
copying will be relatively expensive (a vector-copy). The way I will
accomplish this is to move all closure-creations up to the lowest
lambda-node enclosing the lambda-expression that defines the closure and
which binds a variable the closure captures. I believe this handles the
examples I mentioned in my misleading message of answers and questions.
I think that stating the behavior of EQL on closures to be as Guy
stated means that all implementations must perform the lowest-lambda
analysis in the compiler and interpreter. Perhaps this is too much to
ask---it is too specific a behavior of the implementation.
Once we state that EQL must behave sensibly, hacks to further improve
closure speed may render EQL difficult. Here is a half-baked example
of that, but which is along lines I am pursuing at the moment:
Consider `trivial' closures---for instance, ones that appear
in LABELS, and are simply used to define functions and run them. A better
characterization is that they are closures that are never returned as
values, are never (really) created repeatedly in loops, and which never
are passed as arguments to non-lexically-apparent functions. For these,
I'd like to CONS them once - at load time. Guy's example on page 75 of the
Laser edition is good, but even if the functions in the LABELS were to
close over some variables, these closures can be created once at load-time,
and their bindings could be updated on each entry to the appropriate LAMBDA.
Now, I imagine that I cannot write an analysis routine that will guarantee
to locate exactly these cases correctly. To preserve correctness, I must
be conservative, and therefore I must actually CONS in cases where I might
not be required to CONS.
The upshot is that if I were to know that EQL closures were actually
EQ, then extending EQL to closures is trivial. I would know this is if
my analysis routines could decide every function. But since I don't think
such analysis routines can be written, I must CONS, and maybe I must
needlessly CONS. So, I will be making closures that are EQL, but which
are not EQ.
Therefore, in the S-1 implementation, extending EQL to closures would
mean, pretty much, that EQL would have a do a vector-equal, cut off at the
element level, to test closures. That is, two closures would be EQL if
the vectors representing each had elements where each pair were EQL (or
maybe just if some specific pairs were EQL).
Here are some more examples:
(do ((a ()))
(<test> a)
(push (FOO) a))
(defun foo () (lambda (q)...))
Does this produce a list of EQ elements? I don't know the anwswer, but
I suspect that referential transparency means that the lowest lambda
that binds a variable captured in the closure can be considered to
be above the DO, and so the method I mentioned above for deciding when
to CONS implies that these closures are EQ.
Here's another:
(do ((a ())
(b ...))
(<test> a)
(push (FOO b) a))
(defun foo (x) (lambda (q)...x...))
This must produce an EQ-disjoint list, and the test above implies that.
∂29-Jun-83 1036 RPG Clarification of closures
∂22-Jun-83 2056 FAHLMAN@CMU-CS-C Clarification of closures
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 22 Jun 83 20:56:07 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 22 Jun 83 23:23:38 EDT
Date: Wed, 22 Jun 1983 23:23 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Guy.Steele@CMU-CS-A
Cc: Dick Gabriel <RPG@SU-AI>
Subject: Clarification of closures
In-reply-to: Msg of 22 Jun 83 2302 EDT () from Guy.Steele at CMU-CS-A
If you understand the questions to RPG's answers, or vice versa, could
you enlighten me? I seem to be seeing only a part of this exchange, and
am not sure my implementation is right. (It follows your QEVALB, so if
that's right I'm probably OK.)
At the risk of sounding like Hedrick, I don't like the sound of the last
sentence in your last note. Anything that hairs up EQL, even by one
extra case, slows down the whole universe, and had better be worth the
cost. Or was there an implicit ":-)" in there?
-- Scott
∂29-Jun-83 1037 RPG Clarification of closures
∂22-Jun-83 2037 FAHLMAN@CMU-CS-C Clarification of closures
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 22 Jun 83 20:36:50 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 22 Jun 83 23:35:29 EDT
Date: Wed, 22 Jun 1983 23:35 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Guy.Steele@CMU-CS-A
Cc: Dick Gabriel <RPG@SU-AI>
Subject: Clarification of closures
In-reply-to: Msg of 22 Jun 83 2302 EDT () from Guy.Steele at CMU-CS-A
I reread RPG's note and yours and I think I understand what you two are
saying. It's fine with me if the cases that are indistinguishable are
PERMITTED to be EQ, as long as this is not required. EQUAL will take
care of itself. I would vigorously oppose the suggestion to have EQL do
anything here that EQ does not do.
-- Scott
∂29-Jun-83 1038 RPG Clarification of closures
∂22-Jun-83 0828 Guy.Steele@CMU-CS-A Clarification of closures
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 22 Jun 83 08:27:51 PDT
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 22 Jun 83 11:20:28 EDT
Date: 22 Jun 83 1103 EDT (Wednesday)
From: Guy.Steele@CMU-CS-A
To: Dick Gabriel <RPG@SU-AI>
Subject: Clarification of closures
CC: Scott.Fahlman <FAHLMAN@CMU-CS-C>
In-Reply-To: "Dick Gabriel's message of 22 Jun 83 02:15-EST"
Well, clarification is certainly needed; in your message, you gave
three examples and then referred to the first, second, third, and last
(last being different from third).
Seriously, this is a very important point and I will put some examples
like the ones you suggested into the manual.
--Q
Well, there were 3 examples with code, and one example was described
in English at the end of the first paragraph. So, the setq case was the
first example, the first piece of code was a DO-loop with no setq was
the second, the second DO-loop with a setq was the third, and the
last example was the DO-loop with the embedded LET. Sounds like 4 examples
to me. (And the last was different from the third).
Seriously, this is a very important point, and the question is stil whether
any of the PUSH examples create lists with each member EQ to each of the rest.
-rpg-
∂29-Jun-83 1108 RPG Seriosity
∂29-Jun-83 1103 @MIT-MC:DLW%SCRC-TENEX%MIT-MC@SU-DSN Seriosity
Received: from MIT-MC by SU-AI with TCP/SMTP; 29 Jun 83 11:03:21 PDT
Received: from SCRC-BORZOI by SCRC-TENEX with CHAOS; Wed 29-Jun-83 12:54:13-EDT
Date: Wednesday, 29 June 1983, 12:54-EDT
From: Daniel L. Weinreb <DLW%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Seriosity
To: Guy.Steele%CMU-CS-A@SU-DSN, moon%scrc-tenex%MIT-MC@SU-DSN,
dlw%scrc-tenex%MIT-MC@SU-DSN, rpg@SU-AI, FAHLMAN%CMU-CS-C@SU-DSN
In-reply-to: The message of 29 Jun 83 00:52-EDT from Guy.Steele at CMU-CS-A
I think infix :: is OK. Back over a year ago when we were first talking
about fixing up the package system, we all assumed that it would be ::
because it just seemed like the most natural thing.
∂29-Jun-83 1401 RPG Seriosity
∂29-Jun-83 1356 @MIT-MC:MOON@SCRC-TENEX Seriosity
Received: from MIT-MC by SU-AI with TCP/SMTP; 29 Jun 83 13:54:53 PDT
Date: Wednesday, 29 June 1983 16:40-EDT
From: MOON at SCRC-TENEX
To: Daniel L. Weinreb <DLW at SCRC-TENEX>, Fahlman at CMU-CS-C,
Guy.Steele at CMU-CS-A, rpg at SU-AI
cc: Moon at SCRC-TENEX
Subject: Seriosity
In-reply-to: The message of 29 Jun 1983 12:54-EDT from Daniel L. Weinreb <DLW@SCRC-TENEX>
Date: Wednesday, 29 June 1983, 12:54-EDT
From: Daniel L. Weinreb <DLW@SCRC-TENEX>
In-reply-to: The message of 29 Jun 83 00:52-EDT from Guy.Steele at CMU-CS-A
Back over a year ago when we were first talking
about fixing up the package system, we all assumed that it would be ::
because it just seemed like the most natural thing.
Not so, if <MMCM>NAMESPACE.* are the archives of that discussion.
:: meant something else (temporary USE-PACKAGE in Common Lisp
terminology). #: meant what it currently means in Common Lisp.
I think infix :: is OK.
I am not unalterably opposed to this. I do think it would be better
to keep :: for something that we don't want to discourage people from
using (we want to discourage people from using the internal-symbol package
prefix). If there is really no better alternative than to use up ::
for internal package prefix I will go along with that, but I'm not
yet convinced.
Incidentally, in my original (this year) proposal for #:, the #
was just a special character in the package name as far as the
reader was concerned. There were none of these terrible issues
with the tokenizer having to parse this stuff. That simplicity
got broken when package names were changed to have the same syntax
as symbols; that change does have its advantages, but I think we
have to finger it as the source of our current problem.
Is (eq ||:foo :foo) true, false, a read error, or a runtime error?
∂30-Jun-83 1129 Rees@YALE misc. stuff
Received: from YALE by SU-AI with TCP/SMTP; 30 Jun 83 11:29:00 PDT
Received: by YALE-BULLDOG via CHAOS; Thu, 30 Jun 83 14:28:21 EDT
Date: Thu, 30 Jun 83 14:20:16 EDT
From: Jonathan Rees <Rees@YALE.ARPA>
Subject: misc. stuff
To: common-lisp@SU-AI.ARPA
Here are some of my random and more-or-less nit-picking remarks about
the Laser Edition.
[1] Will there be a unified index in the next edition of the manual? I
have the impression that Symbolics has decided that it is best to have
one index instead of four or five. I certainly agree.
[2] Is LAMBDA not defined as a special form? If not, then sections 5.2.2
(LAMBDA-expressions) and 7.1.1 (description of FUNCTION) should
make this clear. LAMBDA should be indexed somewhere.
[3] Page 38, section 4.8, description of TYPE-OF: "TYPE-OF of one
argument" should be just "TYPE-OF" (fifth and sixth lines of that
paragraph).
[4] Pages 76 and 99: what is the lexical scope of the body of a macro
definition? I.e., where do free variables (and functions) get their
values? This needs clarification. E.g., what does the following mean?
(setq x 8)
(eval-when (compile) (setq x 2))
(let ((x 5))
(macrolet ((foo (z) `(+ ,z ,x)))
(foo 7)))
Does this evaluate to 9, 12, or 15? Does it matter whether the code is being
"interpreted" or "compiled"? Can the manual be written in such a way as to
let this be explicitly undefined?
[5] Page 196, third example in description of STRING-UPCASE et al.:
(string-upcase "Dr. Livingston, I presume?" 6 10)
should read
(string-upcase "Dr. Livingston, I presume?" :start 6 :end 10)
[6] Page 229. Section name "Shape-Sign Abbreviations" is misleading -
the wo1d "abbreviation" seems pretty random here. Not all syntaxes
introduced by # are abbreviations for anything - that is, there aren't
other equivalent ways to write most of them.
[7] Page 244. Is READ-DELIMITED-LIST defined to side-affect the syntax
of its "char" argument in *READTABLE*, even if only temporarily?
Presumably it would be implemented by temporarily defining a
right-parenthesis-like readmacro character for "char", using
UNWIND-PROTECT or something of the sort. If such an implementation is
permitted, perhaps this should be mentioned.
-Jonathan
-------
∂01-Jul-83 0047 FAHLMAN@CMU-CS-C &optional args in DEFMACRO
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 1 Jul 83 00:47:41 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 1 Jul 83 03:47:47 EDT
Date: Fri, 1 Jul 1983 03:47 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: common-lisp@su-ai
Subject: &optional args in DEFMACRO
Consider the following bit of code:
(defmacro foo (a &optional (b 'b-default))
`(list ,a ,b))
(macroexpand (foo 'bar))
Which of the following is returned by the MACROEXPAND:
X. (list 'bar b-default)
Y. (list 'bar 'b-default)
In other words, is the default argument evaluated at macro-expansion
time or is it quoted -- bound to its variable verbatim. The manual is
silent on this, I think. To me, answer Y (quoted default) seems
intuitively right: since A is bound to a verbatim chunk of the calling
form, and B would be too if the calling form were long enough, it seems
right to bind B to the default form without evaluation. However, the
tradition from Maclisp seems to be that the default is evaluated,
producing answer X. It seems that if you want an expansion like Y, you
have to write the defmacro arglist as (a &optional (b ''b-default)). At
least, that's what Maclisp just did when I tried this -- I'm not sure
how old or how ingrained this decision is.
Opinions? I guess that post-freeze conservatism would dictate that we
should stick with the Maclisp definition, unless this is viewed as
obviously wrong. In any event, the manual needs to be tightened here,
if it's not too late.
-- Scott
∂01-Jul-83 0117 @MIT-MC:MOON@SCRC-TENEX &optional args in DEFMACRO
Received: from MIT-MC by SU-AI with TCP/SMTP; 1 Jul 83 01:16:46 PDT
Date: Friday, 1 July 1983 04:11-EDT
From: MOON at SCRC-TENEX
To: Scott E. Fahlman <Fahlman at CMU-CS-C>
Cc: common-lisp at su-ai
Subject: &optional args in DEFMACRO
In-reply-to: The message of Fri 1 Jul 1983 03:47 EDT from Scott E. Fahlman <Fahlman@CMU-CS-C>
The default values in defmacro are forms, to be evaluated if the corresponding
subform of the invocation of the macro is missing, not automatically-quoted
pieces of data. This provides the most generality. Admittedly this can be
confusing.
∂01-Jul-83 0131 ALAN@MIT-MC &optional args in DEFMACRO
Received: from MIT-MC by SU-AI with TCP/SMTP; 1 Jul 83 01:31:23 PDT
Date: 1 July 1983 04:31 EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: &optional args in DEFMACRO
To: Fahlman @ CMU-CS-C
cc: common-lisp @ SU-AI
In-reply-to: Msg of Fri 1 Jul 1983 03:47 EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: Fri, 1 Jul 1983 03:47 EDT
From: Scott E. Fahlman <Fahlman at CMU-CS-C>
(defmacro foo (a &optional (b 'b-default))
`(list ,a ,b))
(macroexpand (foo 'bar))
Which of the following is returned by the MACROEXPAND:
X. (list 'bar b-default)
Y. (list 'bar 'b-default)
X, (assuming you meant (macroexpand '(foo 'bar))) because its is more
general to allow the user to compute something. I personally would write:
(defmacro foo (a &optional (b `b-default)) ...)
and
(defmacro foo (a &optional (b `'b-default)) ...)
using backquote to emphasize that this is a form that will return a piece
of code as a value. Note that a default is treated just like the body of a
defmacro in terms of when it is evaluated etc. A default in a defun is
also treated identically to the body of a defun.
∂01-Jul-83 1216 GJC@MIT-ML
Received: from MIT-ML by SU-AI with TCP/SMTP; 1 Jul 83 12:16:22 PDT
Date: 1 July 1983 15:15 EDT
From: George J. Carrette <GJC @ MIT-ML>
To: COMMON-LISP @ SU-AI
I get confused trying to figure out why somebody would get confused
with defmacro &optional evaluating its optional form specifications.
∂01-Jul-83 1524 FAHLMAN@CMU-CS-C defmacro &optional
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 1 Jul 83 15:24:04 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 1 Jul 83 18:22:53 EDT
Date: Fri, 1 Jul 1983 18:22 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: common-lisp@su-ai
Subject: defmacro &optional
OK, it sounds like most people who care about this issue prefer to have
the default values for arguments in DEFMACRO be evaluated, as in Maclisp,
since that is more general. I seem to be the only one who finds this
ugly and/or confusing, so it must just be a bug in my internal
representation. The manual should be clarified, preferably with an
example, to make it clear that this is the intended behavior.
-- Scott
∂02-Jul-83 1518 ALAN@MIT-MC +0.0 vs. -0.0 vs. EQL
Received: from MIT-MC by SU-AI with TCP/SMTP; 2 Jul 83 15:17:13 PDT
Date: 2 July 1983 18:17 EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: +0.0 vs. -0.0 vs. EQL
To: Common-Lisp @ SU-AI
The Laser manual explains that the EQL function compares two numbers of the
same type using =. This definition has been found wanting in the face of
"negative zero", which a Common Lisp is allowed to support.
(= +0.0 -0.0) => T according to the IEEE standard, and thus it follows that
(EQUALP +0.0 -0.0) => T as well. It is also clear that (EQ +0.0 -0.0) => NIL.
The question is what about (EQL +0.0 -0.0) and (EQUAL +0.0 -0.0)?
EQUAL is defined to act like EQL on numbers (remember that
(EQUAL 3 3.0) => NIL in Common Lisp), so these two issues stand together.
A strict reading of the Laser manual, which currently says that two numbers
of the same type are EQL just in case they are =, would lead one to
conclude that (EQL +0.0 -0.0) => T. Unfortunately this violates the
principles behind the original design of EQL.
We added EQL to Common Lisp because we felt that certain pairs of otherwise
indistinguishable objects failed to be EQ only for implementation dependent
reasons. For example, two "different" 1000000000's on the CADR Lisp
Machines are possible only because of the word size of the machine. On a
3600 Lisp Machine all such billions are EQ, but all trillions are not. But
on both machines all billions, and all trillions, are EQL. We might define
EQL by saying that two objects are EQL just in case there is a conceivable
Common Lisp implementation in which those "same" two objects would have to
be EQ.
That definition of EQL is in complete agreement with the one in the Laser
manual until one faces minus zero. In no conceivable Common Lisp
implementation is -0.0 EQ to +0.0 (some implementations lack it altogether,
but that isn't the same thing). EQL objects are intended to be
indistinguishable except perhaps by using EQ. Yet -0.0 and +0.0 are
distinguishable, by PRINTing them, or by use of the FLOAT-SIGN function,
for example.
Additionally, having -0.0 be EQUAL to +0.0 would introduce a new twist into
the behavior of EQUAL. +0.0 and -0.0 would become the ONLY pair of objects
that have distinct printed representations, yet are considered EQUAL.
I think we must conclude that the Laser manual is simply being imprecise
when it explains that EQL uses = to compare numbers, and that in fact we
want it to be the case that (EQL +0.0 -0.0) => NIL.
∂02-Jul-83 2249 RPG Seriosity
∂02-Jul-83 2054 Guy.Steele@CMU-CS-A Seriosity
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 2 Jul 83 20:54:44 PDT
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 2 Jul 83 23:46:50 EDT
Date: 2 Jul 83 2351 EDT (Saturday)
From: Guy.Steele@CMU-CS-A
To: Scott.Fahlman <FAHLMAN@CMU-CS-C>
Subject: Seriosity
CC: moon%scrc-tenex@MIT-MC, dlw%scrc-tenex@MIT-MC, rpg@SU-AI
You can't use #| to terminate a #| because, unlike |...|, it is defined
to nest properly, so you have to be able to distinguish the open from
the close.
∂02-Jul-83 2249 RPG Seriosity
∂02-Jul-83 2109 FAHLMAN@CMU-CS-C Seriosity
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 2 Jul 83 21:09:11 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 3 Jul 83 00:09:23 EDT
Date: Sun, 3 Jul 1983 00:09 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: Guy.Steele@CMU-CS-A
Cc: dlw%scrc-tenex@MIT-MC, moon%scrc-tenex@MIT-MC, rpg@SU-AI
Subject: Seriosity
In-reply-to: Msg of 2 Jul 83 2351 EDT () from Guy.Steele at CMU-CS-A
Good point about #| having to nest. If we require whitespace after |#,
then I think the problem goes away in general (assuming that nobody
starts using whitespace characters as legal sharp-macros). I would
favor that requirement whether or not we decide to do something else
with qualified symbols because of look-ahead problems.
-- Scott
∂02-Jul-83 2312 @MIT-MC:DLW@SCRC-TENEX +0.0 vs. -0.0 vs. EQL
Received: from MIT-MC by SU-AI with TCP/SMTP; 2 Jul 83 23:12:45 PDT
Date: Sunday, 3 July 1983 02:13-EDT
From: DLW at SCRC-TENEX
to: Common-Lisp at SU-AI
Subject: +0.0 vs. -0.0 vs. EQL
In-reply-to: The message of 2 Jul 1983 18:17 EDT from Alan Bawden <ALAN at MIT-MC>
Alan's message is a concise summary of the conclusions reached on an
internal mailing list at Symbolics; all of the Symbolics team supports
everything Alan says.
∂03-Jul-83 1154 KMP@MIT-MC (EQL -0.0 +0.0) => NIL
Received: from MIT-MC by SU-AI with TCP/SMTP; 3 Jul 83 11:54:17 PDT
Date: 3 July 1983 14:54 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
Subject: (EQL -0.0 +0.0) => NIL
To: common-lisp @ SU-AI
I definitely support the arguments presented in ALAN's note for making
(EQL -0.0 +0.0) return NIL. Any other interpretation would pretty much
destroy the useful properties of EQL's semantics.
I would definitely also want
(EQUAL '(DEFUN FOO () -0.0) '(DEFUN FOO () +0.0))
to return NIL.
Perhaps changing the wording on p56 to "numbers of the same type with the
same sign and magnitude" and omitting the reference to "=" would do; or
would this not be appropriately general to complexes?
∂04-Jul-83 0954 @MIT-MC:DLW%SCRC-TENEX%MIT-MC@SU-DSN misc. stuff
Received: from MIT-MC by SU-AI with TCP/SMTP; 4 Jul 83 09:54:24 PDT
Received: from SCRC-BORZOI by SCRC-TENEX with CHAOS; Mon 4-Jul-83 11:07:18-EDT
Date: Monday, 4 July 1983, 11:06-EDT
From: Daniel L. Weinreb <DLW%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: misc. stuff
To: Rees%YALE@SU-DSN, common-lisp@SU-AI
In-reply-to: The message of 30 Jun 83 14:20-EDT from Jonathan Rees <Rees at YALE>
Date: Thu, 30 Jun 83 14:20:16 EDT
From: Jonathan Rees <Rees@YALE.ARPA>
[1] Will there be a unified index in the next edition of the manual? I
have the impression that Symbolics has decided that it is best to have
one index instead of four or five. I certainly agree.
Yes, we have. Actually, I think we now belive that it's best to have
both kinds, but the one at the back (the one that's easy to find) should be
a combined index. Guy, Jan Walker has figured out some good ways to do
this in Scribe.
[4] Pages 76 and 99: what is the lexical scope of the body of a macro
definition? I.e., where do free variables (and functions) get their
values? This needs clarification. E.g., what does the following mean?
(setq x 8)
(eval-when (compile) (setq x 2))
(let ((x 5))
(macrolet ((foo (z) `(+ ,z ,x)))
(foo 7)))
Does this evaluate to 9, 12, or 15? Does it matter whether the code is being
"interpreted" or "compiled"? Can the manual be written in such a way as to
let this be explicitly undefined?
Well, I think it's always the case that if you run around using
eval-when, things can behave differently "evaluted" than "compiled". I
definitely do not think things like this should be left undefined; this
is a fundamental issue of evaluation semantics. I think the only viable
possibility is that it is defined to return 15 evaluated and 9 compiled,
never 12.
[7] Page 244. Is READ-DELIMITED-LIST defined to side-affect the syntax
of its "char" argument in *READTABLE*, even if only temporarily?
Presumably it would be implemented by temporarily defining a
right-parenthesis-like readmacro character for "char", using
UNWIND-PROTECT or something of the sort. If such an implementation is
permitted, perhaps this should be mentioned.
I agree, since this is exactly how we were going to implement it (I
haven't gotten around to it yet).
∂04-Jul-83 1931 fateman%UCBKIM@Berkeley Re: +0.0 vs. -0.0 vs. EQL
Received: from UCB-VAX by SU-AI with TCP/SMTP; 4 Jul 83 19:30:51 PDT
Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.346/3.33)
id AA00564; 4 Jul 83 18:34:22 PDT (Mon)
Date: 2 Jul 83 18:30:27 PDT (Sat)
From: fateman%UCBKIM@Berkeley (Richard Fateman)
Subject: Re: +0.0 vs. -0.0 vs. EQL
Message-Id: <8307030130.7982@UCBKIM.ARPA>
Received: by UCBKIM.ARPA (3.340/3.5)
id AA07982; 2 Jul 83 18:30:27 PDT (Sat)
To: @SU-AI:ALAN@MIT-MC, Common-Lisp@SU-AI
If +0 and -0 conventions are implemented by means of an IEEE standard
conforming arithmetic system, then they will compare equal at the
instruction level. Who is implementing CL on the CDC 6400?
∂05-Jul-83 1553 GJC@MIT-MC Who is implementing CL on the CDC 6400?
Received: from MIT-MC by SU-AI with TCP/SMTP; 5 Jul 83 15:53:40 PDT
Date: 5 July 1983 18:53 EDT
From: George J. Carrette <GJC @ MIT-MC>
Subject: Who is implementing CL on the CDC 6400?
To: fateman%UCBKIM @ UCB-VAX
cc: Common-Lisp @ SU-AI
Ask me that one again in about 3 months.
∂05-Jul-83 1957 RPG MEMBERP et al
To: hedrick@RUTGERS
CC: "#COMMON.MSG[COM,LSP]"@SU-AI
On this issue of divergence from `Lisp,' which primitives
do you question, and what suggestions would you have for
accomodation of the newer primitives? For example, do you
have name changes that you think would be a reasonable
solution? Or do you believe that many other facets of the language
are to un-Lisplike?
It is apparent to me that full Common Lisp is not practical for
small machines, like the 68000-based machines, and that either
a subset of full Common Lisp will become prevalent or an automatic
tool will be needed to translate full Common Lisp into a suitable
subset for actual use.
Therefore I am sympathetic to complaints along these lines. I also
feel that, even at this late date, we must listen to all legitimate
dissatifaction.
-rpg-
∂06-Jul-83 1123 Rees@YALE more misc. stuff
Received: from YALE by SU-AI with TCP/SMTP; 6 Jul 83 11:22:51 PDT
Received: by YALE-BULLDOG via CHAOS; Wed, 6 Jul 83 14:12:03 EDT
Date: Wed, 6 Jul 83 14:10:00 EDT
From: Jonathan Rees <Rees@YALE.ARPA>
Subject: more misc. stuff
To: common-lisp@SU-AI.ARPA
More nits.
[4, continued] Note that there was nothing special about MACROLET as
opposed to DEFMACRO or MACRO in my previous message. The following is just
as confusing as the MACROLET example (remember that Common Lisp has lexical
closures).
(let ((x 5))
(defmacro foo (z) `(+ ,z ,x))
(foo 7))
Also, what about the following:
(flet ((foo (z) z))
(defmacro foo (z) `(+ ,z ,x))
(foo 7))
Does the DEFMACRO alter the global function binding of FOO or the local
function binding?
[8] Page 77: be careful about the use of the term "predicate". It has
"traditionally" been used in two different ways - to mean a function
which returns a truth value, and to mean an expression which computes a
truth value. The CL manual elsewhere suggests the term "test" for the
second concept. So in the descriptions of IF, WHEN, and UNLESS, use
"test" instead of "pred" to name the test form.
[9] On naming of predicates: maybe there should be an explanation
somewhere of how it is that some predicates are named with a "P" suffix,
and others with a "-P" suffix. E.g.:
input-stream-p
compiled-function-p
simple-string-p
macro-p
but
streamp
functionp
string-charp
stringp
characterp
zerop
char-greaterp
uppercasep
What's the general rule? I have a feeling there almost is one.
-------
∂06-Jul-83 1151 CELLIO@CMU-CS-C.ARPA Re: more misc. stuff
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 6 Jul 83 11:51:24 PDT
Received: ID <CELLIO@CMU-CS-C.ARPA>; 6-Jul-83 14:53:10
Date: Wed 6 Jul 83 14:53:06-EDT
From: Dragon <CELLIO@CMU-CS-C.ARPA>
Subject: Re: more misc. stuff
To: Rees@YALE.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: Message from "Jonathan Rees <Rees@YALE.ARPA>" of Wed 6 Jul 83 14:47:09-EDT
about -p vs p:
the rule Guy is using is that if the thing to get a predicate has
a hyphen in its name, and the p applies to the entire thing (eg.
compiled-function, simple-string, string-char) then it gets a -p.
If the thing does not have a hyphen (stream, zero, etc) or has a
hyphen but the predicate would only apply to the part after the
hyphen (can't think of an example but I know there's one out there
somewhere) then it gets just a p. This has been corrected in the
as-yet-unfinished followup to the laser edition.
Monica
-------
∂06-Jul-83 1337 @MIT-MC:MOON@SCRC-TENEX more misc. stuff
Received: from MIT-MC by SU-AI with TCP/SMTP; 6 Jul 83 13:36:41 PDT
Date: Wednesday, 6 July 1983 16:34-EDT
From: MOON at SCRC-TENEX
To: Jonathan Rees <Rees at YALE>
Cc: common-lisp at SU-AI
Subject: more misc. stuff
In-reply-to: The message of Wed 6 Jul 83 14:10:00 EDT from Jonathan Rees <Rees@YALE.ARPA>
Date: Wed, 6 Jul 83 14:10:00 EDT
From: Jonathan Rees <Rees@YALE.ARPA>
[8] Page 77: be careful about the use of the term "predicate". It has
"traditionally" been used in two different ways - to mean a function
which returns a truth value, and to mean an expression which computes a
truth value. The CL manual elsewhere suggests the term "test" for the
second concept. So in the descriptions of IF, WHEN, and UNLESS, use
"test" instead of "pred" to name the test form.
But a number of functions (including the sequence function) take a :TEST
keyword whose value is a predicate function, not a form. So using the
words predicate/test to reflect the function/form distinction will still
be confusing. We either need a third word or else should append "-form"
to anything that is a form. Fixed in Lambda calculus.
∂08-Jul-83 2316 RPG Destructuring &aux ?
∂20-Jun-83 0814 @SU-SCORE.ARPA,@MIT-XX:Moon@SCRC-TENEX Destructuring &aux ?
Received: from SU-SCORE by SU-AI with TCP/SMTP; 20 Jun 83 08:14:17 PDT
Received: from MIT-XX by SU-SCORE.ARPA with TCP; Mon 20 Jun 83 08:15:42-PDT
Received: from SCRC-EUPHRATES by SCRC-SPANIEL with CHAOS; Mon 20-Jun-83 00:44:52-EDT
Date: Monday, 20 June 1983, 00:44-EDT
From: David A. Moon <Moon at SCRC-TENEX>
Subject: Destructuring &aux ?
To: Scott E. Fahlman <Fahlman at CMU-CS-C>
Cc: steele at CMU-CS-C, moon%scrc-tenex at MIT-MC,
dlw%scrc-tenex at MIT-MC, rpg at SU-AI
In-reply-to: The message of 19 Jun 83 23:58-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
I didn't intend to imply that aux variables should destructure. Sorry about the
loose wording (oops, burble, glub, there goes another ship!)
∂08-Jul-83 2317 RPG Seriosity
∂29-Jun-83 1356 @MIT-MC:MOON@SCRC-TENEX Seriosity
Received: from MIT-MC by SU-AI with TCP/SMTP; 29 Jun 83 13:54:53 PDT
Date: Wednesday, 29 June 1983 16:40-EDT
From: MOON at SCRC-TENEX
To: Daniel L. Weinreb <DLW at SCRC-TENEX>, Fahlman at CMU-CS-C,
Guy.Steele at CMU-CS-A, rpg at SU-AI
cc: Moon at SCRC-TENEX
Subject: Seriosity
In-reply-to: The message of 29 Jun 1983 12:54-EDT from Daniel L. Weinreb <DLW@SCRC-TENEX>
Date: Wednesday, 29 June 1983, 12:54-EDT
From: Daniel L. Weinreb <DLW@SCRC-TENEX>
In-reply-to: The message of 29 Jun 83 00:52-EDT from Guy.Steele at CMU-CS-A
Back over a year ago when we were first talking
about fixing up the package system, we all assumed that it would be ::
because it just seemed like the most natural thing.
Not so, if <MMCM>NAMESPACE.* are the archives of that discussion.
:: meant something else (temporary USE-PACKAGE in Common Lisp
terminology). #: meant what it currently means in Common Lisp.
I think infix :: is OK.
I am not unalterably opposed to this. I do think it would be better
to keep :: for something that we don't want to discourage people from
using (we want to discourage people from using the internal-symbol package
prefix). If there is really no better alternative than to use up ::
for internal package prefix I will go along with that, but I'm not
yet convinced.
Incidentally, in my original (this year) proposal for #:, the #
was just a special character in the package name as far as the
reader was concerned. There were none of these terrible issues
with the tokenizer having to parse this stuff. That simplicity
got broken when package names were changed to have the same syntax
as symbols; that change does have its advantages, but I think we
have to finger it as the source of our current problem.
Is (eq ||:foo :foo) true, false, a read error, or a runtime error?
∂08-Jul-83 2319 RPG Seriosity
∂01-Jul-83 0017 FAHLMAN@CMU-CS-C Seriosity
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 1 Jul 83 00:16:58 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 1 Jul 83 03:17:22 EDT
Date: Fri, 1 Jul 1983 03:17 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: moon%scrc-tenex@mit-mc, dlw%scrc-tenex@mit-mc, steele@CMU-CS-C,
rpg@su-ai
Cc: fahlman@CMU-CS-C
Subject: Seriosity
In-reply-to: Msg of 29 Jun 1983 16:40-EDT from MOON at SCRC-TENEX
I could live with any of the proposed solutions to the |#: problem, I
suppose, but I think that we want to be as conservative as possible in
making changes at this point. For that reason, I would favor the
proposal to require whitespace after #|...|#, which looks to me like the
minimal perturbation that would solve the problem, and which would
impose essentially no extra cognitive load on the user. (I can't
imagaine any situation in which I would not put whitespace there, so I
don't have to worry about it.)
If the business about |#' and the one-character look-ahead really is a
screw for Symbolics, I would go along with changing the infix qualifier
to ::, but I'm not too happy with this.
I'm not adamantly opposed to the proposal that we outlaw ||'s around the
package name, but that would reopen an issue that was explicitly voted
on and that generated a fair amount of discussion last time around.
Reopening this might lead to all sorts of people popping up with new
issues or wanting to reopen old ones.
I guess that since #\| can no longer be a macro (unless we cheat on a
few things), we need to define a new reader-syntax category for |-like
escape behavior.
I think that this problem arises out of the coincidence of a lot of
things. As Moon suggests, the symbol-like syntax for package names in
qualifiers is one problem, but the non-standard use of the sharp
"prefix" character in #|...|# is also a contributor. I wonder if that
last |# might not want to be #| or something else? It might not look as
nice as a delimiter, but it would work better.
-- Scott
∂08-Jul-83 2322 RPG Pathname query
∂05-Jul-83 2041 FAHLMAN@CMU-CS-C Pathname query
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 5 Jul 83 20:40:55 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 5 Jul 83 23:40:30 EDT
Date: Tue, 5 Jul 1983 23:40 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: steele@CMU-CS-C, rpg@su-ai, moon%scrc-tenex@mit-mc,
dlw%scrc-tenex@mit-mc
Cc: fahlman@CMU-CS-C, declisp@CMU-CS-C
Subject: Pathname query
In the description of PARSE-NAMESTRING, it says that this function does
parsing but no merging, and mentions that the CONVENTION and DEFAULTS
argument supply a host merely as a way to guide the parsing. I take it
from that description that this host does not end up in the pathname
that is returned. So if you call parse-namestring on some hostless file
like "foo.bar", the pathname ends up with a host field of NIL,
regardless of what is in the convention or default. Right?
If so, the bit about parsing an empty string producing a pathname with
NIL in all components EXCEPT THE HOST is somewhat bogus.
If not, the manual needs to say clearly that EVERY pathname must have a
host, and PARSE-NAMESTRING will grab one from the convention or default
argument if necessary.
-- Scott
∂08-Jul-83 2323 RPG Pathname query
∂05-Jul-83 2157 FAHLMAN@CMU-CS-C Pathname query
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 5 Jul 83 21:55:20 PDT
Received: ID <FAHLMAN@CMU-CS-C>; 6 Jul 83 00:54:21 EDT
Date: Wed, 6 Jul 1983 00:54 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To: MOON%SCRC-TENEX@mit-mc
Cc: declisp@CMU-CS-C, dlw%SCRC-TENEX@mit-mc, rpg@su-ai,
steele@CMU-CS-C, fahlman@CMU-CS-C
Subject: Pathname query
In-reply-to: Msg of 6 Jul 1983 00:13-EDT from MOON at SCRC-TENEX
Well, this is the reason I suggested a separate CONVENTION field -- you
could have a pathname that knows its behavior is unix-like, without
having to specify the host. The host could come in from a default
during a later merge. If every pathname has to have a host, there's no
way to tell whether the user really specified the host or whether he
really wanted to say "parse this as though the host were the same type
of system as X".
That's OK with me, since in practice you will probably always want to
specify a host during the parse anyway. I just want to be sure that
we're clear on the implications. I'm still not entirely happy with any
of this pathname stuff, but can live with it until we start work on the
second edition; maybe then I'll try to come up with something better.
CONVENTION is still around as an argument to PARSE-NAMESTRING since it
was around in Laser -- what we decided was that there would be no
separate CONVENTION field and that the CONVENTION argument to
PARSE-NAMESTRING would accept a host-name and extract from it the
convention to use. If we all agree with Moon's position, then the
CONVENTION argument to PARSE-NAMESTRING should turn back into HOST (as
it is in Zetalisp) to minimize confusion about what values it takes and
what it does.
-- Scott
∂08-Jul-83 2325 RPG Request for clarification of destructuring DEFMACRO
∂08-Jul-83 2056 Guy.Steele@CMU-CS-A Request for clarification of destructuring DEFMACRO
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 8 Jul 83 20:55:46 PDT
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 8 Jul 83 23:49:29 EDT
Date: 8 Jul 83 2350 EDT (Friday)
From: Guy.Steele@CMU-CS-A
To: fahlman@CMU-CS-C, rpg@SU-AI, dlw%scrc-tenex@MIT-MC,
moon%scrc-tenex@MIT-MC
Subject: Request for clarification of destructuring DEFMACRO
I understand that we have voted for destructuring DEFMACRO,
but I am unsure as to the precise interpretation of the result.
I can think of two plausible interpretations:
(1) Anywhere in the lambda-list where a parameter name (other than a
supplied-p parameter name) may appear, and where the ordinary
lambda-list syntax would not otherwise permit a list (this stipulation
to remove ambiguity), then a destructuring list may appear. This list
may be dotted by a parameter name, and may contain parameter names and
other destructuring lists.
(2) Anywhere in the lambda-list where a parameter name (other than a
supplied-p parameter name) may appear, and where the ordinary
lambda-list syntax would not otherwise permit a list (this stipulation
to remove ambiguity), then a LAMBDA-LIST may appear. Moreover,
a lambda-list (at any level) may be dotted by a parameter name
(say "foo"), and it is as if the lambda-list has been terminated
by "&rest foo" instead of ". foo".
If you think about it carefully, you will see that interpretation (2)
is a strict superset of interpretation (1). It allows one to write
(defmacro dolist ((var listform &optional resultform) &rest body)
...)
and
(defmacro with-open-file ((var fileform &key (direction :input)
(element-type :string-char)
(if-exists nil if-exists-p)
(if-does-not-exist nil
if-does-not-exist-p))
&rest body)
...)
and things like that. Is (2) a desirable and acceptable interpretation
of the ballot result?
--Guy
∂08-Jul-83 2326 RPG Request for clarification of destructuring DEFMACRO
∂08-Jul-83 2117 FAHLMAN@CMU-CS-C.ARPA Request for clarification of destructuring DEFMACRO
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 8 Jul 83 21:16:52 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; 9-Jul-83 00:17:00
Date: Sat, 9 Jul 1983 00:16 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: Guy.Steele@CMU-CS-A.ARPA
Cc: dlw%scrc-tenex@MIT-MC.ARPA, moon%scrc-tenex@MIT-MC.ARPA, rpg@SU-AI.ARPA
Subject: Request for clarification of destructuring DEFMACRO
In-reply-to: Msg of 8 Jul 83 2350 EDT () from Guy.Steele at CMU-CS-A
I think that Guy's option 2 (let variables be replaced by full lambda
lists for destructuring) is a rather far-fetched interpretation of what
was voted on, but I think that it is a good move. Guy's examples
demonstrate that this is useful, and it is no harder to implement than
vanilla destructuring. Nested &optional clauses are pretty awful, but
so are all of the alternatives if that is what you need.
-- Scott
∂11-Jul-83 0942 RPG Request for clarification of destructuring DEFMACRO
∂11-Jul-83 0354 FAHLMAN@CMU-CS-C.ARPA Request for clarification of destructuring DEFMACRO
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 11 Jul 83 03:54:43 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; 11-Jul-83 06:25:43
Date: Sun, 10 Jul 1983 14:30 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: Guy.Steele@CMU-CS-A.ARPA
Cc: dlw%scrc-tenex@MIT-MC.ARPA, moon%scrc-tenex@MIT-MC.ARPA, rpg@SU-AI.ARPA
Subject: Request for clarification of destructuring DEFMACRO
In-reply-to: Msg of 8 Jul 83 2350 EDT () from Guy.Steele at CMU-CS-A
Looks like the "Gang of Five" all agree that your "interpretation" of
destructuring defmacro as allowing recursive lambda-lists is a good one.
You can decide whether it is worth polling Common-Lisp about this,
announcing a clarification, or just slipping this into the manual.
There should be no objection to this change if someone is willing to
supply working code for the parser. I should have our parser fixed up
by the end of today. (However, I will probably only do number-of-args
checking at top-level, unless I can think of some really clean way to do
it for sub-levels.)
-- Scott
∂11-Jul-83 0943 RPG Request for clarification of destructuring DEFMACRO
∂11-Jul-83 0357 @MIT-MC:MOON@SCRC-TENEX Request for clarification of destructuring DEFMACRO
Received: from MIT-MC by SU-AI with TCP/SMTP; 11 Jul 83 03:57:07 PDT
Date: Saturday, 9 July 1983 14:58-EDT
From: MOON at SCRC-TENEX
To: Guy.Steele at CMU-CS-A
Cc: dlw at SCRC-TENEX, fahlman at CMU-CS-C, rpg at SU-AI
Subject: Request for clarification of destructuring DEFMACRO
In-reply-to: The message of 8 Jul 83 2350 EDT from Guy.Steele@CMU-CS-A
Alternative 1 (& keywords only at top level) is what the Lisp machine has
now (except that the part of alternative 2 allowing a defmacro lambda list
to be dotted as an alternative syntax for &rest is also included).
Alternative 2 (& keywords at any level) is better in my opinion. We
won't have any trouble implementing this, I am sure.
Some Lisp machine code currently relies on what alternative 2 would
call "lack of error checking". Thus
(defmacro foo ((variable value) &body body) ...)
may be invoked by
(foo (x) ...body...)
without complaint, and the macro will see value as nil. Currently putting
an &optional between variable and value will cause an error message from
defmacro. I don't think we would have any difficulties with this minor
incompatibility.
I never found the time to finish my destructuring essay that I promised
right after the last ballot. It's about 1/3 done but I have no idea
when it will be possible to finish it.
∂11-Jul-83 0943 RPG Request for clarification of destructuring DEFMACRO
∂08-Jul-83 2117 FAHLMAN@CMU-CS-C.ARPA Request for clarification of destructuring DEFMACRO
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 8 Jul 83 21:16:52 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; 9-Jul-83 00:17:00
Date: Sat, 9 Jul 1983 00:16 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: Guy.Steele@CMU-CS-A.ARPA
Cc: dlw%scrc-tenex@MIT-MC.ARPA, moon%scrc-tenex@MIT-MC.ARPA, rpg@SU-AI.ARPA
Subject: Request for clarification of destructuring DEFMACRO
In-reply-to: Msg of 8 Jul 83 2350 EDT () from Guy.Steele at CMU-CS-A
I think that Guy's option 2 (let variables be replaced by full lambda
lists for destructuring) is a rather far-fetched interpretation of what
was voted on, but I think that it is a good move. Guy's examples
demonstrate that this is useful, and it is no harder to implement than
vanilla destructuring. Nested &optional clauses are pretty awful, but
so are all of the alternatives if that is what you need.
-- Scott
∂11-Jul-83 0944 RPG Request for clarification of destructuring DEFMACRO
∂08-Jul-83 2056 Guy.Steele@CMU-CS-A Request for clarification of destructuring DEFMACRO
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 8 Jul 83 20:55:46 PDT
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 8 Jul 83 23:49:29 EDT
Date: 8 Jul 83 2350 EDT (Friday)
From: Guy.Steele@CMU-CS-A
To: fahlman@CMU-CS-C, rpg@SU-AI, dlw%scrc-tenex@MIT-MC,
moon%scrc-tenex@MIT-MC
Subject: Request for clarification of destructuring DEFMACRO
I understand that we have voted for destructuring DEFMACRO,
but I am unsure as to the precise interpretation of the result.
I can think of two plausible interpretations:
(1) Anywhere in the lambda-list where a parameter name (other than a
supplied-p parameter name) may appear, and where the ordinary
lambda-list syntax would not otherwise permit a list (this stipulation
to remove ambiguity), then a destructuring list may appear. This list
may be dotted by a parameter name, and may contain parameter names and
other destructuring lists.
(2) Anywhere in the lambda-list where a parameter name (other than a
supplied-p parameter name) may appear, and where the ordinary
lambda-list syntax would not otherwise permit a list (this stipulation
to remove ambiguity), then a LAMBDA-LIST may appear. Moreover,
a lambda-list (at any level) may be dotted by a parameter name
(say "foo"), and it is as if the lambda-list has been terminated
by "&rest foo" instead of ". foo".
If you think about it carefully, you will see that interpretation (2)
is a strict superset of interpretation (1). It allows one to write
(defmacro dolist ((var listform &optional resultform) &rest body)
...)
and
(defmacro with-open-file ((var fileform &key (direction :input)
(element-type :string-char)
(if-exists nil if-exists-p)
(if-does-not-exist nil
if-does-not-exist-p))
&rest body)
...)
and things like that. Is (2) a desirable and acceptable interpretation
of the ballot result?
--Guy
∂11-Jul-83 1736 RPG [COMSAT: Msg of Saturday, 9 July 1983 17:40 EDT] I just gotta try again.
∂11-Jul-83 1328 ALAN@MIT-MC [COMSAT: Msg of Saturday, 9 July 1983 17:40 EDT] I just gotta try again.
Received: from MIT-MC by SU-AI with TCP/SMTP; 11 Jul 83 13:28:23 PDT
Date: 11 July 1983 15:50 EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: [COMSAT: Msg of Saturday, 9 July 1983 17:40 EDT] I just gotta try again.
To: RPG @ SU-AI
Date: 11 July 1983 06:56 EDT
From: Communications Satellite <COMSAT>
To: ALAN
Re: Msg of Saturday, 9 July 1983 17:40 EDT
FAILED: RPG at SU-AI; Recipient name apparently rejected.
Last reply was: {500 Syntax error in recipient specification.}
Failed message follows:
-------
Date: 9 July 1983 17:40 EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: Request for clarification of destructuring DEFMACRO
To: RPG @ SU-AI, Guy.Steele @ CMU-CS-A, Fahlman @ CMU-CS-A,
DLW @ SCRC-TENEX, Moon @ SCRC-TENEX
Steele's option (2) is precisely what I have been planning to add to
LispMachine Lisp for years. I have an implementation of this that only
lacks &key support, otherwise I would have installed it already.
∂12-Jul-83 1449 @MIT-MC:hes%VIXEN%MIT-MC@SU-DSN function specs
Received: from MIT-MC by SU-AI with TCP/SMTP; 12 Jul 83 14:49:35 PDT
Received: from SCRC-HOUSATONIC by SCRC-TENEX with CHAOS; Tue 12-Jul-83 17:38:39-EDT
Date: Tuesday, 12 July 1983, 17:42-EDT
From: Howard Shrobe <hes%VIXEN%MIT-MC@SU-DSN>
Subject: function specs
To: common-lisp@SU-AI
Hi, while working on notes for a AAAI tutorial that I'm giving with
Larry Masinter, I was informed that Common Lisp provides no means
for defining a functional property of a symbol. I.e. you can't
do the MacLisp
(defun (foo bar) (x) (mumble-frotz x))
or even the LispMachine Lisp
(defun (:property foo bar) (x) (mumble-frotz x)).
I was shocked. I often write programs which work by dispatching to
functions stored on property lists. Short of flavors or some such
thing this is the cleanest style for coding many problems.
Now without at least this minimal form of function-spec you're forced
to do something much grosser:
Option 1 is to do
(putprop 'foo #'(lambda (x) (mumble-frotz x)) 'bar)
in which case the compiler will probably not compile
the lambda expression.
Option 2 is to build a macro
(defmacro deffunny (name (symbol indicator) &body body)
(let ((standin (gensym)))
`(progn 'compile
(defun ,standin ,args ,@body)
(putprop ',symbol (fsymeval ',standin) ',indicator))))
which is vintage 1973 MacLisp whose demise was welcomed by all when the
extended defun was introduced.
Can someone please explain to me what is being gained by not having
function-specs.
Naively
Howie Shrobe
∂12-Jul-83 1820 Masinter.PA@PARC-MAXC.ARPA Re: function specs
Received: from PARC-MAXC by SU-AI with TCP/SMTP; 12 Jul 83 18:19:16 PDT
Date: 12 Jul 83 18:18:52 PDT (Tuesday)
From: Masinter.PA@PARC-MAXC.ARPA
Subject: Re: function specs
In-reply-to: hes%VIXEN%MIT-MC's message of Tue, 12 Jul 83 17:42 EDT
To: Howard Shrobe <hes%VIXEN%MIT-MC@SU-DSN.ARPA>
cc: common-lisp@SU-AI.ARPA
Howie, as I recall (my manual is missing and I must recall), the
(defun (foo bar) (x) (mumble-frotz x))
was disallowed, but that the first arg to defun COULD be an arbitrary
SETFable form. I guess you have to write
(defun (getprop foo bar) (x) (mumble-frotz x))
[apologies for bastard CommonLisp, but as I said, I don't have my manual
handy].
∂12-Jul-83 1923 @SU-SCORE.ARPA,@MIT-XX:BENSON@SPA-NIMBUS function specs
Received: from SU-SCORE by SU-AI with TCP/SMTP; 12 Jul 83 19:22:25 PDT
Received: from MIT-XX by SU-SCORE.ARPA with TCP; Tue 12 Jul 83 19:26:48-PDT
Date: Tuesday, 12 July 1983, 19:17-PDT
From: BENSON at SPA-Nimbus
Subject: function specs
To: Howard Shrobe <hes%VIXEN%MIT-MC at SU-DSN>, common-lisp at SU-AI
In-reply-to: The message of 12 Jul 83 14:42-PDT from Howard Shrobe <hes%VIXEN%MIT-MC at SU-DSN>
I believe that function specs were not included in Common Lisp because
of the number of issues which they raised. I don't believe there were
any strong objections to the concept itself, rather to the secondary
consequnces of including them, such as:
It is a pervasive language feature, comparable to type specifiers in
scope, which would require a similar amount of explanation.
It adds yet another semantic interpretation of lists, which conflicts with
some existing ones, e.g. #'(lambda ...) and #'(:property ...) have very
different meanings. It also means that lists need to be used where only
symbols are now allowed, such as in RETURN-FROM block names. This may
require changing some equality tests from EQ or EQL to EQUAL.
For consistency, ((:property foo bar) x) should be legal as well as
(funcall #'(property foo bar) x). This is not currently the case in
Zetalisp.
Despite these problems, I think that function specs probably should be
included in Common Lisp in the next edition, if we can stand another round
of discussion on something as fraught with peril as this. They are
quite useful.
Regarding another point in your message, it is very unfortunate that
#'(lambda ...) forms not inside defuns are not compiled. For example,
one might store functions in a hash table rather than on the property
list of a symbol. A command processor might use an array of functions
indexed by character codes. There is no function spec which refers to an
entry in a hash table or an element of an array. This forces one into
your Option 2 kludge if you want the function to be compiled.
-- Eric
∂12-Jul-83 1923 FAHLMAN@CMU-CS-C.ARPA function specs
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 12 Jul 83 19:21:45 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 12 Jul 83 22:22:54-EDT
Date: Tue, 12 Jul 1983 22:22 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: Howard Shrobe <hes%VIXEN%MIT-MC@SU-DSN.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: function specs
In-reply-to: Msg of 12 Jul 1983 17:42-EDT from Howard Shrobe <hes%VIXEN%MIT-MC at SU-DSN>
Let me try to reconstruct the history of functions specs (or their lack)
in Common Lisp.
1. The Symbolics folks at one point noticed the lack of function specs and
proposed adding a rather complex, fully extensible set of machinery for
function specs.
2. There was a bit of confusion surrounding the whole thing -- several
other complicated things, such as support for a flavor system, were
being discussed at the same time and seemed to interact with this
proposal. The proposal was also wrapped in some unfortunate terminology
about function specs being the "name" of a function. That further
confused the issue. This way of looking at it seemed natural to Moon
et. al. but very unnatural to some of the rest of us. Anyway, the
terminology was separable from the mechanics of the function spec
proposal, but some of us didn't realize this in time. The result was
that a number of us of us (including me) boggled at the apparent
complexity of what was being proposed and began looking for a less
complicated way of accomplishing the same end.
3. I came up with the idea of using any SETF-able form in the "name"
slot of DEFUN as the place to put the resulting lambda or compiled
function. (A symbol in that position would be special, in that the
function goes in the FUNCTION cell rather than the VALUE cell.) It
seemed to me that this had the advantage of not requiring a whole new
set of machinery for defining these pseudo-names. However, my proposal
had some bugs as well.
4. Both proposals attracted considerable support. We decided to leave
the issue unresolved for the moment and think about it, rather than to
arbitrarily grab one solution or the other. In the meantime, the
solution of making up a name (or having a macro do it as you illustrated)
seemed an entirely workable, if ugly, solution.
5. In the recent rush to wrap up the remaining loose ends so that Guy
could get the manual out, I indicated to Moon that I was ready to accept
a slightly simplified version of his proposal if he wanted to try again,
but we both agreed that reopening this issue would probably lead to
a lot of debate. We decided not to try to resolve this issue for the
first edition of the manual, but to discuss it again after the first
edition is out.
So that's why Common Lisp does not currently include function specs. An
implementation is allowed to add some sort of function spec as an
extension. My guess is that when we all recover from the recent manual
debate and the ensuing damage control, function specs will be one of the
first items on the agenda. If we can all agree this time (and I am
optimistic that we will), then these will go into all implementations
sometime soon as an advertised extension, and will become "official"
when the second edition of the manual comes out.
Isn't politics fun?
-- Scott
∂12-Jul-83 1945 KMP@MIT-MC Historical Footnote
Received: from MIT-MC by SU-AI with TCP/SMTP; 12 Jul 83 19:45:22 PDT
Date: 12 July 1983 22:44 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
Subject: Historical Footnote
To: hes @ SCRC-VIXEN
cc: Common-Lisp @ SU-AI
Date: Tuesday, 12 July 1983, 17:42-EDT
From: Howard Shrobe <hes%VIXEN%MIT-MC@SU-DSN>
Re: function specs
To: common-lisp@SU-AI
...
(defmacro deffunny (name (symbol indicator) &body body)
(let ((standin (gensym)))
`(progn 'compile
(defun ,standin ,args ,@body)
(putprop ',symbol (fsymeval ',standin) ',indicator))))
which is vintage 1973 MacLisp whose demise was welcomed by all
when the extended defun was introduced...
Well, allowing for the obvious bugs in this definition
(ARGS isn't bound anywhere, NAME isn't used, etc.), the 1973 syntax
would have been...
(defun deffunny macro (form)
(prog (temp symbol indicator body standin)
(setq temp (car (setq form (cdr form))))
(setq args (car (setq form (cdr form))))
(setq body (cdr form))
(setq symbol (car temp))
(setq indicator (cadr temp))
(setq standin (gensym))
(return (list 'progn ''compile
(cons 'defun (cons standin (cons args body)))
(list 'defprop symbol standin indicator)))))
Of course, this STILL would not have worked reliably since if I'm not mistaken
gensyms lose their uniqueness when output by the compiler, so you'd have
interned symbols that looked like G0017 all over the place and if you loaded
the results of separate compilations which had had the same gensym counter,
you'd be clobbering functions back and forth accidentally. So this is, even
today, not a reliable strategy.
No heavy-duty point to be made here. Just wanted to remind you what "common"
lisp looked like in 1973. We have come a longer way than you might remember.
Still, as is obvious from the holes in the language, we have a long ways to
go. The belief seems to be that premature standardization would be far worse
than living with certain parts of the language fuzzily defined while we think
things out...
∂13-Jul-83 2008 EAK@MIT-MC function specs
Received: from MIT-MC by SU-AI with TCP/SMTP; 13 Jul 83 20:08:40 PDT
Date: 13 July 1983 23:00 EDT
From: Earl A. Killian <EAK @ MIT-MC>
Subject: function specs
To: common-lisp @ SU-AI
In-reply-to: Msg of 12 Jul 1983 17:42-EDT from Howard Shrobe <hes%VIXEN%MIT-MC at SU-DSN>
Btw, I would consider any compiler that didn't compile the lambda in
(putprop 'foo #'(lambda (x) (mumble-frotz x)) 'bar)
to be broken.
∂14-Jul-83 0743 @USC-ECL,@MIT-MC:BSG%SCRC@MIT-MC function specs
Received: from USC-ECL by SU-AI with TCP/SMTP; 14 Jul 83 07:40:42 PDT
Received: from MIT-MC by USC-ECL; Thu 14 Jul 83 07:39:50-PDT
Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Thu 14-Jul-83 10:27:37-EDT
Date: Thursday, 14 July 1983, 10:35-EDT
From: Bernard S. Greenberg <BSG%SCRC@MIT-MC>
Subject: function specs
To: EAK@MIT-MC, common-lisp%SU-AI@USC-ECL
In-reply-to: The message of 13 Jul 83 23:00-EDT from Earl A. Killian <EAK at MIT-MC>
Date: 13 July 1983 23:00 EDT
From: Earl A. Killian <EAK @ MIT-MC>
Btw, I would consider any compiler that didn't compile the lambda in
(putprop 'foo #'(lambda (x) (mumble-frotz x)) 'bar)
to be broken.
Surely, if the form above appears in the middle of a function.
But what about forms that appear at the top level? I don't think there
is a clear notion of what happens to top level forms that are not
macro invocations. Traditionally, these forms go into the object file
unmodified (just encoded). Should constant expressions be reduced?
Should diagnostics be issued? Should internal macro calls be expanded?
In order for the compiler to compile lambdas in top level forms, a solid
theory of processing top-level function calls has to be developed, which
implies a new, fundamental mode of meta-evaluation, viz., compiler-top-level,
to be added to the current set of language-defined meta-evaluations
(true evaluation and compilation).
∂14-Jul-83 1233 @USC-ECL,@MIT-XX:BENSON@SPA-NIMBUS Top level forms in a compiled file
Received: from USC-ECL by SU-AI with TCP/SMTP; 14 Jul 83 11:59:31 PDT
Received: from MIT-XX by USC-ECL; Thu 14 Jul 83 11:57:43-PDT
Date: Thursday, 14 July 1983, 11:54-PDT
From: BENSON at SPA-Nimbus
Subject: Top level forms in a compiled file
To: Bernard S. Greenberg <BSG%SCRC at MIT-MC>, EAK at MIT-MC,
common-lisp%SU-AI at USC-ECL
In-reply-to: The message of 14 Jul 83 07:35-PDT from Bernard S. Greenberg <BSG%SCRC at MIT-MC>
Received: from USC-ECL by SU-AI with TCP/SMTP; 14 Jul 83 07:40:42 PDT
Received: from MIT-MC by USC-ECL; Thu 14 Jul 83 07:39:50-PDT
Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Thu 14-Jul-83 10:27:37-EDT
Date: Thursday, 14 July 1983, 10:35-EDT
From: Bernard S. Greenberg <BSG%SCRC@MIT-MC>
Subject: function specs
To: EAK@MIT-MC, common-lisp%SU-AI@USC-ECL
In-reply-to: The message of 13 Jul 83 23:00-EDT from Earl A. Killian <EAK at MIT-MC>
Date: 13 July 1983 23:00 EDT
From: Earl A. Killian <EAK @ MIT-MC>
Btw, I would consider any compiler that didn't compile the lambda in
(putprop 'foo #'(lambda (x) (mumble-frotz x)) 'bar)
to be broken.
Surely, if the form above appears in the middle of a function.
But what about forms that appear at the top level? I don't think there
is a clear notion of what happens to top level forms that are not
macro invocations. Traditionally, these forms go into the object file
unmodified (just encoded). Should constant expressions be reduced?
Should diagnostics be issued? Should internal macro calls be expanded?
In order for the compiler to compile lambdas in top level forms, a solid
theory of processing top-level function calls has to be developed, which
implies a new, fundamental mode of meta-evaluation, viz., compiler-top-level,
to be added to the current set of language-defined meta-evaluations
(true evaluation and compilation).
There is a solution to this problem. Collect all the top level
forms in the file into a function of no arguments and compile the
function. When the compiled file is loaded, call the function and throw
it away. This is the strategy I chose for PSL's compiler and binary
loader. Thus, anonymous lambdas outside of named function definitions
are compiled by the same means as those which are inside functions.
Other advantages are conceptual simplicity, ease of implementation, and
faster loading.
There are problems with this approach. The top-level function which
must be compiled is sometimes huge, much larger than any real function.
Compilation is slower. People tend to be much sloppier in what they
write at the top level than inside functions (because they never
expected it to be compiled!). Top level forms sometimes modify the
global state such that a monolithic compilation does not have the same
semantics as incremental evaluation. The most common example of the
latter is package manipulation, which changes the behavior of the
reader.
Whether or not this exact approach is taken, I think it is quite
reasonable to expect top level forms in a file being compiled to be
treated the same as forms within function definitions, including
diagnostics, constant sharing and compilation of lambda forms.
-- Eric
∂14-Jul-83 1324 @USC-ECL,@MIT-XX:BENSON@SPA-NIMBUS Top level forms in a compiled file
Received: from USC-ECL by SU-AI with TCP/SMTP; 14 Jul 83 11:59:31 PDT
Received: from MIT-XX by USC-ECL; Thu 14 Jul 83 11:57:43-PDT
Date: Thursday, 14 July 1983, 11:54-PDT
From: BENSON at SPA-Nimbus
Subject: Top level forms in a compiled file
To: Bernard S. Greenberg <BSG%SCRC at MIT-MC>, EAK at MIT-MC,
common-lisp%SU-AI at USC-ECL
In-reply-to: The message of 14 Jul 83 07:35-PDT from Bernard S. Greenberg <BSG%SCRC at MIT-MC>
Received: from USC-ECL by SU-AI with TCP/SMTP; 14 Jul 83 07:40:42 PDT
Received: from MIT-MC by USC-ECL; Thu 14 Jul 83 07:39:50-PDT
Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Thu 14-Jul-83 10:27:37-EDT
Date: Thursday, 14 July 1983, 10:35-EDT
From: Bernard S. Greenberg <BSG%SCRC@MIT-MC>
Subject: function specs
To: EAK@MIT-MC, common-lisp%SU-AI@USC-ECL
In-reply-to: The message of 13 Jul 83 23:00-EDT from Earl A. Killian <EAK at MIT-MC>
Date: 13 July 1983 23:00 EDT
From: Earl A. Killian <EAK @ MIT-MC>
Btw, I would consider any compiler that didn't compile the lambda in
(putprop 'foo #'(lambda (x) (mumble-frotz x)) 'bar)
to be broken.
Surely, if the form above appears in the middle of a function.
But what about forms that appear at the top level? I don't think there
is a clear notion of what happens to top level forms that are not
macro invocations. Traditionally, these forms go into the object file
unmodified (just encoded). Should constant expressions be reduced?
Should diagnostics be issued? Should internal macro calls be expanded?
In order for the compiler to compile lambdas in top level forms, a solid
theory of processing top-level function calls has to be developed, which
implies a new, fundamental mode of meta-evaluation, viz., compiler-top-level,
to be added to the current set of language-defined meta-evaluations
(true evaluation and compilation).
There is a solution to this problem. Collect all the top level
forms in the file into a function of no arguments and compile the
function. When the compiled file is loaded, call the function and throw
it away. This is the strategy I chose for PSL's compiler and binary
loader. Thus, anonymous lambdas outside of named function definitions
are compiled by the same means as those which are inside functions.
Other advantages are conceptual simplicity, ease of implementation, and
faster loading.
There are problems with this approach. The top-level function which
must be compiled is sometimes huge, much larger than any real function.
Compilation is slower. People tend to be much sloppier in what they
write at the top level than inside functions (because they never
expected it to be compiled!). Top level forms sometimes modify the
global state such that a monolithic compilation does not have the same
semantics as incremental evaluation. The most common example of the
latter is package manipulation, which changes the behavior of the
reader.
Whether or not this exact approach is taken, I think it is quite
reasonable to expect top level forms in a file being compiled to be
treated the same as forms within function definitions, including
diagnostics, constant sharing and compilation of lambda forms.
-- Eric
∂14-Jul-83 1351 @USC-ECL,@MIT-MC:BSG%SCRC@MIT-MC Top level forms in a compiled file
Received: from USC-ECL by SU-AI with TCP/SMTP; 14 Jul 83 13:50:52 PDT
Received: from MIT-MC by USC-ECL; Thu 14 Jul 83 13:49:38-PDT
Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Thu 14-Jul-83 16:40:06-EDT
Date: Thursday, 14 July 1983, 16:47-EDT
From: Bernard S. Greenberg <BSG%SCRC@MIT-MC>
Subject: Top level forms in a compiled file
To: BENSON%NIMBUS@MIT-MC, EAK@MIT-MC, common-lisp%SU-AI@USC-ECL
In-reply-to: The message of 14 Jul 83 14:54-EDT from BENSON at SPA-NIMBUS
Date: Thursday, 14 July 1983, 11:54-PDT
From: BENSON at SPA-Nimbus
Date: Thursday, 14 July 1983, 10:35-EDT
From: Bernard S. Greenberg <BSG%SCRC@MIT-MC>
In order for the compiler to compile lambdas in top level forms, a solid
theory of processing top-level function calls has to be developed
There is a solution to this problem. Collect all the top level
forms in the file into a function of no arguments and compile the
function. When the compiled file is loaded, call the function and throw
it away. This is the strategy I chose for PSL's compiler and binary
loader. Thus, anonymous lambdas outside of named function definitions
are compiled by the same means as those which are inside functions.
Other advantages are conceptual simplicity, ease of implementation, and
faster loading.
Yes and no. This causes exactly the right things to happen to the forms
themselves, but...
There are problems with this approach. The top-level function which
must be compiled is sometimes huge, much larger than any real function.
Compilation is slower. People tend to be much sloppier in what they
write at the top level than inside functions (because they never
expected it to be compiled!). Top level forms sometimes modify the
global state such that a monolithic compilation does not have the same
semantics as incremental evaluation. The most common example of the
latter is package manipulation, which changes the behavior of the
reader.
The evaluation order here is absolutely critical, and kills your whole thing.
It is completely reasonable and extraordinarily common to call functions
defined two lines above. I guess you could say, "Well, run it at the end,
not at the beginning", but there could be load-time forms in your functions.
I had often thought of compiling a little functionelle for each top-level
form.
∂14-Jul-83 1442 KMP@MIT-MC
Received: from MIT-MC by SU-AI with TCP/SMTP; 14 Jul 83 14:42:00 PDT
Date: 14 July 1983 17:41 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
To: BSG @ SCRC-TENEX
cc: Common-Lisp @ SU-AI
Date: Thursday, 14 July 1983, 16:47-EDT
From: Bernard S. Greenberg <BSG%SCRC@MIT-MC>
... I had often thought of compiling a little functionelle for each
top-level form.
I basically like this idea. You'd of course have to check first that it didn't
macroexpand into def-forms, eval-when, etc. Just define (FOO) to mean
the same as (DEFUN G0001 () (FOO)) (G0001). It wouldn't have to be implemented
the same; just have equivalent behavior.
I seem to recall that the reason (or one of the reasons) for Maclisp not
compiling random toplevel forms was due to address space. Binary space can't
(straightforwardly) be reclaimed, so things like Macsyma which were address-
space critical wanted to do lots of set-up stuff as toplevel forms so it
could all be GC'd. Even on large address space machines, I could see
putting such definitions on their own pages so they could get reclaimed while
leaving the rest of the definitions loaded with them near each other to
reduce paging.
Taking this scheme literally might also mean compiler warnings for special
vars, undefined functions, etc. I think I could even learn to like that.
Technically, people can currently write
(PROGN (DEFUN F () (FOO ...))
(DEFMACRO FOO ...)
(F))
and expect to win. FOO could even call F if the writer were creative.
I'm willing to claim such code is bogus. The user can always fall back on
(EVAL '(...))
if he wants truly uncompiled code.
∂14-Jul-83 2001 @MIT-MC:BENSON@SPA-NIMBUS Compiling top level forms
Received: from MIT-MC by SU-AI with TCP/SMTP; 14 Jul 83 19:53:37 PDT
Date: Thursday, 14 July 1983, 18:34-PDT
From: BENSON at SPA-Nimbus
Subject: Compiling top level forms
To: Kent M. Pitman <KMP at MIT-MC>, BSG at SCRC-TENEX
Cc: Common-Lisp at SU-AI
In-reply-to: The message of 14 Jul 83 14:41-PDT from Kent M. Pitman <KMP at MIT-MC>
From: Kent M. Pitman <KMP @ MIT-MC>
To: BSG @ SCRC-TENEX
cc: Common-Lisp @ SU-AI
I seem to recall that the reason (or one of the reasons) for Maclisp not
compiling random toplevel forms was due to address space. Binary space can't
(straightforwardly) be reclaimed, so things like Macsyma which were address-
space critical wanted to do lots of set-up stuff as toplevel forms so it
could all be GC'd. Even on large address space machines, I could see
putting such definitions on their own pages so they could get reclaimed while
leaving the rest of the definitions loaded with them near each other to
reduce paging.
PSL also does not GC compiled code, but explicitly allocates and
deallocates the space for the toplevel function. No pointer to it can
be kept, in fact it never even exists as a full-fledged Lisp object. It
could even conceivably be allocated on the stack (Yow!). Seriously,
such a beast could be put in a temporary area on the 3600 and win big.
∂14-Jul-83 2012 Guy.Steele@CMU-CS-A Top-level forms
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 14 Jul 83 20:12:45 PDT
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 14 Jul 83 22:54:36 EDT
Date: 14 Jul 83 2309 EDT (Thursday)
From: Guy.Steele@CMU-CS-A
To: common-lisp@SU-AI
Subject: Top-level forms
I strongly advocate that Common LISP compilers perform processing
on top-level forms equivalent to making the form into a function
of no arguments, compiling that, and then invoking it.
--Guy
∂14-Jul-83 2020 @USC-ECL,@MIT-MC:BENSON@SPA-NIMBUS Top level forms in a compiled file
Received: from USC-ECL by SU-AI with TCP/SMTP; 14 Jul 83 20:20:26 PDT
Received: from MIT-MC by USC-ECL; Thu 14 Jul 83 18:13:03-PDT
Date: Thursday, 14 July 1983, 18:13-PDT
From: BENSON at SPA-Nimbus
Subject: Top level forms in a compiled file
To: Bernard S. Greenberg <BSG at SCRC>, BENSON at NIMBUS, EAK at MIT-MC,
common-lisp%SU-AI%USC-ECL at MIT-MC
In-reply-to: The message of 14 Jul 83 13:47-PDT from Bernard S. Greenberg <BSG at SCRC>
The evaluation order here is absolutely critical, and kills your whole thing.
It is completely reasonable and extraordinarily common to call functions
defined two lines above. I guess you could say, "Well, run it at the end,
not at the beginning", but there could be load-time forms in your functions.
This is handled in PSL by having function definitions add a call to FSET
to the list of top level forms to be compiled. It is exactly as if
DEFUN were just defined as a macro and didn't cause any special behavior
on the part of the compiler! Just wrap (lambda () ...) around
everything in the file, and compile it. (Not actually true, but the
behavior is the same.) E.g.
(defmacro defun (name &body body)
`(setf (symbol-function ',name)
#',(lambda ,@body)))
Even defining a function twice in a single file and using both
definitions works.
∂14-Jul-83 2027 JONL.PA@PARC-MAXC.ARPA Re: Top-level forms
Received: from PARC-MAXC by SU-AI with TCP/SMTP; 14 Jul 83 20:27:28 PDT
Date: 14 JUL 83 20:23 PDT
From: JONL.PA@PARC-MAXC.ARPA
Subject: Re: Top-level forms
To: Guy.Steele@CMUA.ARPA, common-lisp@SAIL.ARPA
cc: JONL.PA@PARC-MAXC.ARPA
In response to the message sent 14 Jul 83 23:09 EDT (Thursday) from
Guy.Steele@CMU-CS-A.ARPA
Comments aside about compilng to "save space" etc (Interlisp *does*
GC the compiled code objects, but still doesn't compile the top-level
forms), I'm glad you used the phrase "equivalent to", for that
allows a compiler/processor merely to macro-reduce the top-level
form to standard primitive lisp and output that.
Remember in MacLisp when we met the problem of top-level forms
that used macros available to the compile-time environment, but not
installed in the load-time environment?
Still, this isn't a simple problem, for GSB (I think) had to have a
way to defeat the macro-reduction of such forms, in one instance.
∂16-Jul-83 1407 KMP@MIT-MC Top level forms in a compiled file
Received: from MIT-MC by SU-AI with TCP/SMTP; 16 Jul 83 14:07:13 PDT
Date: 16 July 1983 17:06 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
Subject: Top level forms in a compiled file
To: BENSON @ SPA-NIMBUS
cc: Common-Lisp @ SU-AI
In-reply-to: Msg of 14 Jul 1983 18:13-PDT from BENSON at SPA-Nimbus
Date: Thursday, 14 July 1983, 18:13-PDT
From: BENSON at SPA-Nimbus
... This is handled in PSL by having function definitions add a call to FSET
to the list of top level forms to be compiled. It is exactly as if ...
(defmacro defun (name &body body)
`(setf (symbol-function ',name) #',(lambda ,@body)))
Even defining a function twice in a single file and using both
definitions works...
I assume you meant #'(lambda ,@body) rather than #',(lambda ,@body).
In any case, now that you mention it, I once wrote a simple Lisp compiler
which used this same trick. This style of presentation is also satisfactory
to me. It is maximally parallel with scheme, where
(setf (symbol-function ',name) #'(lambda ,@body))
would "macroexpand" to
(setq ,name (lambda ,@body))
In fact, it's probably a loss to have the primitive conceptual unit not be
#'(lambda ...), since anything else is almost sure to eventually turn up
deficient for some extension to def- syntax.
So I'd support this as a semantic model. Actually, named-lambda might be better
than lambda, but that's no big deal.
What follows is just speculation; not in any way a proposal. It's interesting
to note that if
FILE1 = [ (defun f (x) x) (defun g (x) x) ]
"means" roughly...
(defun g0001 (x) x)
(defun g0002 (x) x)
(defun g0003 () (setf #'f #'g0001) (setf #'g #'g0002))
then (load "FILE1") is the same as (G0003) so we could in principle have a
function PRELOAD which was like LOAD but just "got everything in core" without
doing any major side-effects. Then (LOAD "FILE1") might just do (G0003) without
having to move bits from disk to core. Also, there might be a function RELOAD
which just re-ran G0003 rather than moving a second set of the code into core.
It wouldn't fix bashed constants, but that might either be know to be desirable
or at least harmless for some applications.
∂17-Jul-83 0901 @MIT-MC:DLW%SCRC%MIT-MC@SU-DSN Top level forms in a compiled file
Received: from MIT-MC by SU-AI with TCP/SMTP; 17 Jul 83 09:01:01 PDT
Received: from SCRC-BORZOI by SCRC-TENEX with CHAOS; Sun 17-Jul-83 11:44:26-EDT
Date: Sunday, 17 July 1983, 11:52-EDT
From: Daniel L. Weinreb <DLW%SCRC%MIT-MC@SU-DSN>
Subject: Top level forms in a compiled file
To: KMP%MIT-MC@SU-DSN
Cc: Common-Lisp@SU-AI
In-reply-to: The message of 16 Jul 83 17:06-EDT from Kent M. Pitman <KMP at MIT-MC>
Date: 16 July 1983 17:06 EDT
From: Kent M. Pitman <KMP at MIT-MC>
What follows is just speculation; not in any way a proposal...
...we could in principle have a
function PRELOAD which was like LOAD but just "got everything in core" without
doing any major side-effects. Then (LOAD "FILE1") might just do (G0003) without
having to move bits from disk to core.
In our work on the Lisp Machine, we sometimes have to LOAD in Lisp
programs that the LOAD mechanism is based on, like pieces of the network
software or local file system software. Boy, is it a pain! Your
PRELOAD feature might be a good way to handle that.
∂20-Jul-83 2032 @USC-ISIB,DDYER@USC-ISIB list of lisps
Received: from USC-ISIB by SU-AI with TCP/SMTP; 20 Jul 83 20:32:22 PDT
Date: 20 Jul 1983 1619-PDT
Subject: list of lisps
From: Dave Dyer <DDYER@USC-ISIB>
To: common-lisp@SU-AI
Has anyone got a master list of LISP implementations, all dialects,
all machines? I get soooo tired of ennumerating all the rumors I remember.
-------
∂25-Jul-83 1235 @MIT-MC:Server@SPA-NIMBUS Failed mail
Received: from MIT-MC by SU-AI with TCP/SMTP; 25 Jul 83 12:35:07 PDT
Date: Thursday, 21 July 1983, 07:22-PDT
From: Mail Server at SPA-Nimbus
Subject: Failed mail
To: Mail Maintainers
Redistributed-to: common-lisp at su-ai at mc
Redistributed-by: rsl at SPA-Nimbus
Redistributed-date: Friday, 22 July 1983, 18:36-PDT
Unable to deliver to the following recipient:
Common-Lisp at SU-AI: Host not responding.
----- Failed message follows -----
Date: Friday, 15 July 1983, 15:29-PDT
From: BENSON at SPA-Nimbus
Subject: Re: Top level forms in a compiled file
To: Martin.Griss <Griss at UTAH-20>, Common-Lisp at SAIL
In-reply-to: The message of 15 Jul 83 12:07-PDT from Martin.Griss <Griss at UTAH-20>
Date: 15 Jul 1983 1307-MDT
From: Martin.Griss <Griss@UTAH-20>
Subject: Re: Top level forms in a compiled file
To: BENSON@SPA-NIMBUS
cc: Griss@UTAH-20
In-Reply-To: Your message of 14-Jul-83 2127-MDT
Should also mention that sometimes need COMPILETIME or BOTHTIMES to also get
the execution of functions that used in defining forms to be compiled further
on. MACRO definitions are explicitly BOTHTIMES..
Martin
-------
That's a separate issue, but one that should also be
addressed by the standard. On the Lisp Machine, macros aren't actually
defined in the global compile time environment, just saved in a private
place known to the compiler. Only an explicit EVAL-WHEN (COMPILE)
actually puts something in the compile time Lisp world. Compare that
with Arthur Norman's request to make everything evaluated at compile
time by default! The former strategy is designed for the Lisp system
builder, where compiling an incompatible version of part of the existing
environment would be disastrous if things changed out from under him. I
know this happened on many occasions with PSL, especially when
cross-compiling to a new machine. Arthur's suggestion is geared to the
applications programmer, who usually wants the effect of incremental
evaluation even when compiling to a file. I suspect if we were to
survey Lisp programmers who are not Lisp implementors, most would prefer
to have everything defined at compile time. On the other hand, it is
much more than just inconvenient to system implementors if this is the
case. Uh oh, I feel an impending global variable, *EVAL-WHEN-DEFAULT*,
set to (LOAD EVAL) by systems hackers and (COMPILE LOAD EVAL) by real
people. Of course, one had better set it inside an EVAL-WHEN...
-- Eric
∂26-Jul-83 2227 Guy.Steele@CMU-CS-A Re: small snafu in LASER edn.
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 26 Jul 83 22:26:47 PDT
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 27 Jul 83 01:26:01 EDT
Date: 27 Jul 83 0126 EDT (Wednesday)
From: Guy.Steele@CMU-CS-A
To: JoSH <JoSH@RUTGERS>
Subject: Re: small snafu in LASER edn.
CC: common-lisp@SU-AI
In-Reply-To: "JoSH's message of 25 Jul 83 21:52-EST"
The name of the variable should be *load-set-default-pathname*.
It is an error that the description of load mentions
"*load-set-pathname-defaults*".
--Guy
∂28-Jul-83 0952 GBROWN@DEC-MARLBORO.ARPA ERROR SIGNALLING FUNCTIONS
Received: from DEC-MARLBORO by SU-AI with TCP/SMTP; 28 Jul 83 09:52:04 PDT
Date: Thu 28 Jul 83 11:32:42-EDT
From: GBROWN@DEC-MARLBORO.ARPA
Subject: ERROR SIGNALLING FUNCTIONS
To: COMMON-LISP@SU-AI.ARPA
I believe that use of the error signalling macros in
sections 24.3 and 24.4 of the Common Lisp Reference Manual
(Excelsior edition) will diminish the quality of
applications written in Common Lisp. This note explains my
reasoning. I realize that the note comes quite late, but I
sent in a similar note right after Moon's proposal was
distributed which appears to have been ignored. Please
recognize that my opinions are not necessarily those of
other people working on Common Lisp at Digital.
My basic objection is that the macros incorporate
assumptions about error signalling and error messages that
are inapropriate in most circumstances and hence should not
be promoted by the language. I feel quite strongly about
this issue. Here are my specific objections.
o check-type. In all but the most trivial cases, the
user will have no idea how to enter a new value,
and we wouldn't want the user to know anyway. The
first example in the reference manual, telling the
user that something is not a vector of integers, is
precisely an example of an error message I'd hate
for a user to see. The error message fragment
alleviates this problem somewhat, but again only in
trivial cases.
The other problem with this macro is the use of an
unevaluated string for the error message fragment.
This is quite parochial, and certainly would only
suffice in the country in which the application was
written. At Digital, for example, we like to put
our messages in a file that can be edited by the
user, and invoke a function to obtain the message
when needed.
o assert. This suffers from the same shortcomings as
check-type. In particular, the error message is
actually part of the syntax, and thus couldn't be
evaluated in any case! In addition, the assumption
is made that a rational message could be composed
from one of the generalized-variable references in
order to prompt the user for a new value. I
challenge anyone to do this in a stylish fashion
(note that there were no examples of this in the
manual).
o e(c)typecase. I am quite surprised that Common
Lisp implementors were willing to accept the hair
involved in trying to compose a reasonable message
for this function. Imagine trying to word the
message for types such as a defstruct, a deftype,
or even the relatively simple type (or (mod 16)
(member t nil)). And I hope we'd agree that the
resulting message would only confuse the user, who
would have no idea how to enter a new value.
o e(c)case. Except in the situation where there are
only two or three clauses, I doubt if an
application would want to list all the possible
values from which the user can choose. Even
applications that list all possible commands (e.g.,
Visicalc) do it in their own special style.
o declarations. It is not clear how these macros
interact with declarations. If a function declares
the data item used as the key in one of these
macros, it may be that Common Lisp has already
detected the error and, in many implementations,
signalled it with some other obscure error message.
This completely circumvents the error message
generated by the macro, and renders the macro
useless.
Let us reconsider the inclusion of these macros in Common
Lisp. They address a problem, detection and alteration of
incorrect input by the user, which is better addressed by an
application-specific question asking facility. If we retain
these macros, I suggest that they be used only to signal
uncorrectable internal logic errors.
- Paul C. Anagnostopoulos
-------
∂28-Jul-83 1215 @MIT-MC:DLW%SCRC-TENEX%MIT-MC@SU-DSN ERROR SIGNALLING FUNCTIONS
Received: from MIT-MC by SU-AI with TCP/SMTP; 28 Jul 83 12:15:25 PDT
Received: from SCRC-BORZOI by SCRC-TENEX with CHAOS; Thu 28-Jul-83 15:04:26-EDT
Date: Thursday, 28 July 1983, 15:05-EDT
From: Daniel L. Weinreb <DLW%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: ERROR SIGNALLING FUNCTIONS
To: GBROWN%DEC-MARLBORO@SU-DSN, COMMON-LISP@SU-AI
In-reply-to: The message of 28 Jul 83 11:32-EDT from GBROWN at DEC-MARLBORO
I have two answers to your first point about check-arg.
You say that "the user will have no idea how to enter a new value". The
problem with this is your model of what a "user" is. One of the main
users of Common Lisp is the program developer, who is writing the
program, and WILL know how to enter a new value.
You say that this is "an example of an error message I'd hate for a user
to see". Well, suppose there is a data-type mismatch detected at
runtime. Would you rather see this message, or have the program
continue to execute despite the mismatch and do something random, or
blow up, or say "please call an expert, you obviously can't understand
this", or what?
You want to put all your error messages in a big file of error messages.
Well, I think we simply have a difference of religion here. I'd hate to
have to do that; if I did that, I'd never bother to take the trouble to
create good error messages, and my program would be incomprehensible
because when you read the program you wouldn't be able to see the error
messages. How many users really would want to edit this file? What would
they edit? And if you want to make an application multilingual, it's
a lot harder than just replacing the error messages: what about all
the prompts and so on?
For assert, your only new objection ends with "I challenge anyone to do
this in a stylish fashion." Well, I have a great deal of experience
with advanced error systems, and we have had a lot of success in this
area. Challenge accepted. When you get your first official release
of Symbolics Common Lisp, try it.
Besides, if you want to make up your own message, well, don't use
e(c)case. Those functions exist for the convenience of those who don't
want to spend a lot of effort optimizing theis messages.
I think you might have a valid point about the interaction between
the explicit type checking, and implicit type checking that might
be generated because of declarations. If I had an "Excelsior edition"
(so that's what it's called!), I could look into this further.
∂28-Jul-83 1217 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN ERROR SIGNALLING FUNCTIONS
Received: from MIT-MC by SU-AI with TCP/SMTP; 28 Jul 83 12:16:02 PDT
Received: from SCRC-BULLDOG by SCRC-TENEX with CHAOS; Thu 28-Jul-83 15:11:41-EDT
Date: Thursday, 28 July 1983, 15:12-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: ERROR SIGNALLING FUNCTIONS
To: GBROWN%DEC-MARLBORO@SU-DSN
Cc: COMMON-LISP@SU-AI
In-reply-to: The message of 28 Jul 83 11:32-EDT from GBROWN at DEC-MARLBORO
I don't recall seeing your comments before; perhaps your original
message was swallowed by some mail system problem. It wouldn't
be the first time.
Your comments are well taken, but I think underlying this there is a
fundamental disagreement about what Common Lisp is for. Such constructs
as check-type and assert are intended for internal checking within a
program; they are certainly not intended as a user interface for users
of an application program. When a check-type signals an error, it is
assumed that the user is thrown into the debugger. Supplying a new
value is a debugger function suitable for someone who understands the
program and the particular error that occurred. An application program
that is trying to conceal its Lisp underpinnings from its user and
present some consistent facade that differs from the facade the system
presents to Lisp programmers would not allow this error to get into
the debugger. Presumably it would say "Internal error; the program
is broken".
Indeed, Common Lisp in general is a system programming language and is
not itself a framework for constructing user interfaces. At least not
yet; this seems like a good area to address in a "second generation"
of Common Lisp. But I think the conscious decision we made to concentrate
on the easier areas first was wise, considering how long it has taken
just to define the language in all of its details.
Also you should note that check-type and assert are convenient abbreviations,
not the most general error signalling mechanism. So it's supposed to be
okay that you cannot do all possible error signalling with them, for instance
you can't compute an error message at run time. Perhaps this design
decision was wrong; I couldn't say.
The condition system that I intend to propose after the basic language
has been squared away addresses these issues. It is based on the Lisp
Machine condition system, with some improvements and simplifications.